If some .blog file is getting corrupted the ttop aborts upon startup (stops collecting stats)

[kha84]

Hello there!

I've stumbled upon one interesting issue. The machine where ttop was installed, experienced an issue and one of the ttop .blog files was corrupted as a result. Because of this, the ttop refused to start in any mode - either in interactive mode, or in the 'save snapshot' mode:

$ ttop
cannot read from stream
streams.nim(431)         read

$ ttop -s
cannot read from stream
streams.nim(431)         read

$ ll /var/log/ttop/ | tail -n10
-rw-r--r--  1 root root   3323471 Mar 13 23:50 2026-03-13.blog
-rw-r--r--  1 root root   3151405 Mar 14 23:50 2026-03-14.blog
-rw-r--r--  1 root root   3087894 Mar 15 23:50 2026-03-15.blog
-rw-r--r--  1 root root   3231377 Mar 16 23:50 2026-03-16.blog
-rw-r--r--  1 root root   3367939 Mar 17 23:50 2026-03-17.blog
-rw-r--r--  1 root root   3261069 Mar 18 23:50 2026-03-18.blog
-rw-r--r--  1 root root   3262953 Mar 19 23:50 2026-03-19.blog
-rw-r--r--  1 root root   3236584 Mar 20 23:50 2026-03-20.blog
-rw-r--r--  1 root root   3180953 Mar 21 23:50 2026-03-21.blog
-rw-r--r--  1 root root    110592 Mar 22 00:50 2026-03-22.blog <----- last broken file

Here it doesn't really matter what happened with the machine and what exactly caused file corruption. In my particular case I think on Mar 22nd the disk became full so it's not only ttop who couldn't properly finish writing to file :) In the real life it could be all the other possible issues like abnormal reboot / system hang / OOM / whatever.

Thus my feature request to make ttop a bit more bullet proof in this case:

• if any of the .blog file appeared to be corrupted, the ttop should still be able to be executed in a 'save snapshot' mode (-s), so no further performance snapshots will be lost (like in my case I lost the whole week of data)
• it's OK if ttop will be complaining on some .blog file corruption when executed in 'save snapshot' or interactive mode, but to make this message a bit more specific - e.g. to introduce some kind of exception handler that will print something like 'Cannot parse file /var/log/ttop/2026-03-22.blog - most probably file is corrupted'

I'm happy to contribute a PR if needed.
As always - amazing tool, love every bit of it.