Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Force Recheck Not Working in qBT 4.1.6 For Previously Completed Files #10640

Open
Shadowhwk opened this issue May 14, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@Shadowhwk
Copy link

commented May 14, 2019

qBittorrent version and Operating System

4.1.6 x64 on Win10 Pro Ver. 1809 Build 17763.475

What is the problem

This may be related to issue #8917 that was reported to be fixed in 4.1.6 by thalieht who closed that issue on Mar. 24th, 2019.

After upgrading to 4.1.6 per the in-program update check, one of my download drives disappeared on reboot. Somehow it lost its drive letter of G: so the files seeding from that drive all got re-added to the download list. After pausing all seeding and downloads, I then reset the drive letter and rebooted. After reboot I confirmed the missing drive was back in it's normal location and all files appear intact. There is no volume corruption.

I then tried a Force Recheck on the known completed items. This reset them to 0% complete and downloads restarted for a few before I re-paused everything. I double checked the ones that restarted and the completed files still exist and are playable (video and audio content). I then did some research and tried a few of the usual fixes for this issue when qBT closes and the file state is corrupted.

  1. Tried the Set Location for all affected files to the G:\Complete folder where the functional and completed files still exist, and then issued a Force Recheck for a couple of test items. Tried with both the item paused and with the item queued (max active torrents set to 0 to prevent re-downloading. Files still remain at 0% completed even though the file exists and is fine.

  2. Tried copying the file to the empty folder in my qBT temp directory. First left it with the completed filename and then tried by adding the .qb! extension. A Force Recheck in either case still leaves the file(s) in the download queue and also in the Complete folder on the G: drive.

What is the expected behavior

Force Recheck appears to be completely broken for the files affected by this issue. It should be finding the completed and intact files, whether the Force Recheck was issued with the item paused or queued for download. I only wish to re-add these for further seeding to keep my ratio increasing.

Steps to reproduce

No idea but the above description of the issue should indicate that I've tried most of the common fixes that are recommended when the file state is corrupted.

Extra info(if any)

I will be investigating if I can find something with respect to the .parts files for each of the files that got re-added to the download list but thought I'd report the issue 1st. Any suggestions appreciated.

@lev777

This comment has been minimized.

Copy link

commented May 14, 2019

Not a new issue, unfortunately. See arvidn/libtorrent#3134. Arvidn has offered to look at logs - if they could be collected. I didnt find any way to set those parameters with the Windows build.

Partial Workaround for existing cross-seeded torrents: If there is another seed - delete a file from the torrent data and force recheck. Recheck will be able to succeed & then Resume can download missing data and also succeed.

See also https://qbforums.shiki.hu/index.php?topic=6108.0 - issue has apparently persisted for some time.

@Shadowhwk

This comment has been minimized.

Copy link
Author

commented May 14, 2019

Just made this comment on your issue #3134...

I'm not able to delete any files to try the workaround as items are usually single file downloads and some are single seeded. That would defeat the purpose of re-adding/re-creating the torrents as I only want to continue seeding the completed files. As you mentioned above, I will try to look at the logs to see if I can find anything helpful. I still find it interesting that thalieht closed issue #8917 on Mar. 24, 2019 and said the issue will be fixed in 4.1.6. Prior to build 4.1.6 I was able to use force-recheck successfully on other files that had their status corrupted. Is it safe to downgrade to 4.1.5 which had been working fine? I'll also look into the fastresume and parts files as I mentioned in my issue.

@Shadowhwk

This comment has been minimized.

Copy link
Author

commented May 14, 2019

Definitely see an issue in the logs... lots of size mismatch errors, some corrupted .fastresume files that couldn't be re-opened. I tried deleting the .fastresume files (backed up 1st) for those that were shown as corrupted in the logs, but no luck. A Force Recheck still causes the item to be re-added to the download queue even though the file is complete and appears to play fine on the external drive that it was originally moved to after completion.

I did have some success by copying the completed file back to the qbtemp folder where the downloads in progress are already stored. I renamed the file ending in .qb! to .bad and then added the .qb! extension to the known good copy of the file. A Force Recheck after this works but for some reason the file only shows 99.9% complete and takes a couple of minutes to re-complete. At least I don't have to re-download the entire file.

Alas this method is painfully slow as the external drive (and even the internal that the qbtemp folder resides on) are pretty slow for reading/writing. Old drives that I no longer use in my production boxes so relegated to use for my Bittorrent downloads. It would take days to do this process for all completed files, most of which are 5Gb+ in size. Note that this process didn't work for one of the items I tried, It showed no .qb! file in the qbtemp directory so the completed file was copied in, renamed with the .qb! extension but it still won't Force Recheck properly.

I will continue investigating as I won't spend the time required to correct 77+ large files using the above method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.