recheck of finished torrent fails

Bug #610069 reported by Skizmo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qBittorrent
Fix Released
Undecided
Christophe Dumez

Bug Description

I checked the option 'recheck torrent on completion'. As soon as a torrent is done, it checks if it is ok, and it's never ok. Every recheck I see that different parts are missing (which parts are missing is random.. each check gives a different result).

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

- What version of libtorrent-rasterbar are you using?
- Does this happen with all torrents or just one?
- Did you enable the setting to store incomplete torrents in a different folder (temp)?
- Did you enable the setting to append .!qB to incomplete torrents?

Changed in qbittorrent:
assignee: nobody → Christophe Dumez (hydr0g3n)
milestone: none → 2.3.0
status: New → Incomplete
Revision history for this message
Skizmo (skizmo-home) wrote :

-I'm using Ubuntu linux and it is kept up-to-date. This morning I got v2.3.0rc10.

-On of the release candidates caused a crash on my machine each time a torrent was finished, that's why I enabled the recheck. I have 4 torrent right now in queue, and all of them fail the recheck.

- No, I'm not using the temp-dir option.

- No, !qB is not appended to incomplete torrents.

Revision history for this message
Skizmo (skizmo-home) wrote :

Some extra info :

I downloaded a file to see what happens with the rc10 version, and this file had no problems. So I can't be sure if the problem is gone with files that started to download with rc10, or that is simply doesn't happen with all the downloads. The other files that had the problems before stil have the problem with rc10.

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

What seems strange is that torrent checking is achieved by libtorrent, not qBittorrent itself. I don't think you changed your version of libtorrent if you're using my Ubuntu PPA (I don't package libtorrent, you're using the one from Ubuntu).

There is no way qBittorrent can cause a torrent to fail checking. It is true though that an earlier release candidate caused crashes on torrent completion though. It may be possible that these torrents got corrupted because qBittorrent was not done writing the data on the hard drive because it crashed. This may explain why you don't have issues with recent torrents.

However, one thing is for sure, even if they got corrupted, libtorrent should simply redownloading the corrupted pieces after a force-recheck. If I understood correctly, the following behaviour is happening:
- A torrent completes download
- A force-recheck is triggered on completion due to program settings
- An error is found on checking
- The torrent downloads again the corrupted pieces (it does not start from scratch)
- The torrent completes
- checking, error, ... LOOPING

Is that correct?

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

You could try the following:
1. Stop qbittorrent
2. Remove fastresume data:
rm ~/.local/share/data/qBittorrent/BT_backup/*.fastresume
3. Start qBittorrent

I'm also saving fastresume data on torrent completion. It may be possible that some of your fastresume data is corrupt.

Revision history for this message
Skizmo (skizmo-home) wrote :

The looping effect is correct. That is exactly what is happening.

ok... deleting the fastresume data did the trick. Recheck now validates to file after it's done :) thanx for the help.

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

Good. Making this bug as fixed then because I believe this was caused by a previous (buggy) release candidate. If this happens again for new torrents, feel free to reopen this report though.

Thanks for reporting this.

Changed in qbittorrent:
status: Incomplete → Fix Released
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.