Re-check isn't done when it should / manual check feature would be nice

Bug #158773 reported by Ville Aakko
4
Affects Status Importance Assigned to Milestone
libtorrent-rasterbar
Fix Released
Unknown
qBittorrent
Fix Released
Undecided
Christophe Dumez

Bug Description

I'm usin 1.0.0rc6 on Gentoo.

Qbittorrent doesn't automatically recheck torrent's download status when it should.

A couple of times this has happened: when I started qbittorrent, all my downloading torrents were at 0% and started to download right away (without re-check), although some of they were nearer 100% already. I was able to initiate re-check for all my torrents by closing qbittorrent and deleting all .fastresume files in ~/.qbittorrent/backup directory. However, since it is impossible to tell which .fastresume belongs to which torrent, it is not possible to selectively delete those that need re-checking. Not to mention that one should not need a restart of qbittorrent to do a simple re-check.

A few times I have shut down qbittorrent non-cleanly (logged out of KDE without closing it). Though I think I have gotten this behaviour from qbittorrent even when I DID close qbittorrent properly (maybe another bug - .fastresume wasn't updated?).

Suggestions:

1) Qbittorrent should mark all torrents as "unclean" when running (e.g. delete .fastresume if it ins't up-to-date), and mark them "clean" if (or when) shut down properly. That way, qbittorrent can decide if recheck is needed for a particular torrent. Alternatively, it should keep the .fastresume file (somewhat) up-to-date even while running (for example, after every downloaded 50mb or alternatively every 15 minutes or so). A few kb's that are downloaded twice shouldn't matter, but 50% of a 600MB download is perhaps too much...

2) There should be a way to trigger a re-check manually from the UI. This would also come in handy when moving a partial download from another bittorrent client, or to repair a partial download from any other source. Or to work around qbittorrent bugs with automatic re-checks =).

Thanks for a great GUI bittorrent client, though! Keep up the good work!

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

First there is a way to know which fastresume file correspond to which torrent. Just right-click on the torrent and hit properties. You will see the hash on first tab. fast reusme file is <hash>.fastresume.

Secondly, what you said never happened to me but I'll see with libtorrent author if he can maybe make fastresume feature more reliable/safer.

Changed in qbittorrent:
assignee: nobody → hydr0g3n
Changed in libtorrent-rasterbar:
status: Unknown → New
Changed in libtorrent-rasterbar:
status: New → Confirmed
Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

This is fixed in svn. Fast resume data is saved regularly to avoid problems when qBittorrent is not shut down cleanly.

I'm also working on clean exit when unlogging from the window manager.

Changed in qbittorrent:
status: New → Fix Committed
Changed in libtorrent-rasterbar:
status: Confirmed → Fix Released
Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

rc9 is out.

Changed in qbittorrent:
status: Fix Committed → Fix Released
Revision history for this message
Apostolos Proios (gdheadbanger) wrote :

well , it cant seed torrents already downloaded atm. was trying to seed an already downed torrent but with no result. i was doing a check(was able to see the bar fill untill 100%) then dropped back to 0 and started from scratch.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.