search

Tribler / tribler

Privacy enhanced BitTorrent client with P2P content discovery
https://www.tribler.org
GNU General Public License v3.0
4.85k stars 451 forks source link

Global re-checking should be prioritisable #2684

Open vi opened 7 years ago

vi commented 7 years ago
Tribler version/branch+revision:

e744e2ca7090b9f3258694125e52f7fe66194e96 devel

Steps to reproduce the behavior:
  1. Have a collection of files for seeding in "Downloading"
  2. Add one new download
  3. Wait it to be partially downloaded
  4. Crash (or something that triggers global recheck of all downloads)
  5. After starting again, Tribler re-checks all files
Actual behavior:

Tribler re-checks files in random order, with the download I want stuck in "Waiting for check", delaying completion by half an hour, missing network availability opportunities.

Expected behavior:

option 1. Partially downloaded file gets re-checked first (in order to resume download sooner rather than later)
option 2. "Force recheck" is available for "Waiting for check" state downloads and makes the specified download to be checked first (or at least bumps it in checking queue).

devos50 commented 7 years ago

All downloads are checkpointed every five minutes so they shouldn't check if they are checkpoint before that time. When Tribler checkpoints, some resume data is written to the disk.

I recently refactored the checkpointing mechanism since it was not working correctly and sometimes did not write resume data. If you have time, could you verify that resume data is indeed written away to the files in ~/.Tribler/dlcheckpoints? That would help us a lot 👍

vi commented 7 years ago

There are *.state files in ~/.Tribler/dlcheckpoints. Filesytem modification date suggests they are not stale.

What happens if Tribler or computer crashes when writing those state files?