A forceful Tribler quit does not save torrent progress

[teddyrogers]

Tribler 8.0.7, after adding a few torrents let the downloads run as normal. Using 50% as an example reset the machine, do not gracefully quit Tribler.

With the machine rebooted and Tribler running again note the torrents remain in the list. However, the status is back to downloading at 0%. Unless I force Tribler to complete a recheck of the torrent/s it will re-download all 50% of the torrent file again.

I assume progress data of a torrent is saved on completion or during a graceful quit of Tribler. Either that or cache was not able to save to disk in time?

[qstokkink]

I'm not entirely sure if this is a bug or expected behavior. We'll look into it.

[teddyrogers]

@qstokkink what is the frequency and, when does, Tribler save torrent details, stats, ratio's, etc. ?

[qstokkink]

Essentially, the state of a torrent is written to your disk whenever it changes: we call this a "checkpoint" (if you search our code then you will find a lot of mentions of this). This happens when starting, reloading, pausing, receiving metadata updates etc.

A recheck/redownload should only happen if the reloaded state does not match the torrent information it points to. A non-graceful exit does not necessarily cause this, but it is more likely to happen (especially if the torrent is actively downloading).

[teddyrogers]

@qstokkink thank you for the info.

I recently installed some new memory and timings were randomly causing the machine to reboot. I noticed this issue occur a few times so not a once off.

I can't say for certain, as I was not taking particular notice at the time, I believe the ratios were also reset. I'll have to test this to confirm.

[qstokkink]

That makes sense. If the checkpoint is corrupted, all the stats have to be recalculated. That includes the total uploaded and total downloaded metrics, which are used to calculate the ratio.

[qstokkink]

With all the available information in this issue, I believe this is simply expected behavior after a dirty shutdown.

[teddyrogers]

@qstokkink I don't think this should be expected as-is. If I have a torrent with 30 files and select two files to download, leave them to fully download to 100%. Quit Tribler gracefully. Restart Tribler and select a few more random files to download in the torrent. Let it download the files for a while then complete a forceful quit or reset of the system. When restarting Tribler and checking the torrent only the first two files will be checked.

Tribler does not seem to be saving torrent status/ progress until after a complete download, graceful exit or some other specific events/ checkpoints.

The other ongoing issue/s are as noted in previous replies above.

In comparison with other clients, such as qBittorrent and BiglyBT, they do not have the same problem/s.

[qstokkink]

I think Tribler is behaving as designed. Perhaps qBittorrent and BiglyBT, have a different strategy for when they write data to disk. Perhaps that their strategy is even better, we'd have to look into that: but I don't think Tribler is doing something different than we designed it to do. Maybe we should reopen this issue as an "enhancement".

@egbertbouman could you offer a second opinion?

[egbertbouman]

It looks like we only save resume data when the state of a download has changed or when we change the download config. I think it would make sense to do this periodically as well. Right now, a download could be running indefinitely without the resume data ever being saved. After a forceful exit you'll have to start downloading from scratch (or do a recheck) since the have field of the resume data hasn't been stored.

[qstokkink]

I think it would make sense to do this periodically as well.

Alright, let's reopen this to address that then.

[qstokkink]

@egbertbouman I've been looking for a suitable location for a periodic checkpoint mechanism. I'm thinking of adding it to sesscb_states_callback(). Do you know of a better location?

tribler/src/tribler/core/libtorrent/download_manager/download_manager.py

Line 984 in 36453a2

async def sesscb_states_callback(self, states_list: list[DownloadState]) -> None:

[egbertbouman]

@qstokkink Using sesscb_states_callback sounds good to me 👍