-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Re-checking torrents failing and torrents downloading again / Corrupting files #7982
Comments
every single one of my 'finished' torrents that had been completed but marked errored started to redownload. 4000 torrents in my queue after upgrading. There were 20 before. Please god have mercy on me. when i started to delete the new-old downloads and rebooted everything started downloading again. i'm not long for this world |
Yeah... this bug is actually corrupting data. If anyone has not copied their completed torrents elsewhere, they will lose potentially huge amounts of data from this. Fortunately I had already copied most of the data I needed elsewhere, but this has corrupted / deleted a reasonable amount of data, including from some torrents which no longer have seeds, which it is now busy trying to download I think that probably makes it a high priority. I still can't replicate it in an way I can explain... but a few things I've noticed:
|
Same here... I have like 60+ torrent rechecking at every startup for no reason But sometimes I suspect them to reappear back in QBT and so I DL them again without noticing, not sure (sometimes yes sometimes no) |
I'm encountering the same issue on client v4.5.4 right now. The files are being downloaded to an internal HDD. Of the torrents I have setup, my copy of the GDC 2017 torrent has been consistently failing on startup saying the files are missing, rechecking, downloading, rechecking again, downloading again, and so on. After multiple failures, I recognized some of the folder names were consistently coming back incomplete. The strange thing is these folders would either have all the files already, have some of the files, or have incomplete files that couldn't play past a certain point. The other torrents of GDC stuff are not showing signs of the same behavior. The screenshot below shows which folders on my end the client keeps attempting to download and later rechecking and downloading again. |
What do you mean exactly? |
The torrent stays in missing file state until I do something. It only rechecks when I reset its location and force recheck. If I attempt to simply resume it without doing that, it throws an error that it can't restore the torrent:
Yes. After forcing recheck and the torrent finishes rechecking, it then stalls at around 96% and then starts redownloading files from there. I have "re-check on completion" enabled, so it rechecks the files again when the download finishes; but it determines that the files are still missing, stalls again at around 96%, and then tries to redownload those missing files. This cycle continues indefinitely for the same folders it thinks files are missing from. Previously, I didn't have rechecks on completion enabled. In that case, it would say it was complete and seed normally, which is strange if it wasn't actually complete and contained partial/corrupted files. It wouldn't be until I started qBittorrent again that it would again say files are missing, and so I enabled rechecks to see if this was a recurring problem.
Other than the log line above, qBittorrent didn't capture much of note. The execution log isn't throwing other errors or providing more insight into what's happening, and the appdata log doesn't show anything for the days I had experienced the problem. |
Could you disable "recheck on completion", let the torrent to complete downloading again and provide a screenshot of qBittorrent window with this torrent selected and General info pane opened? |
After disabling "recheck on completion", below are a couple images of the general pane with the torrent selected: Some things I've discovered while getting the screenshots:
|
I believe it's the cause of the problem. Need to investigate it a bit... |
There are actually two folders, but somehow they merge and files with the same name end up in the same folder. |
IIRC, |
Having the same issue as @arctic-carbide with the same files in the same torrent, for what it's worth. qbittorrent-nox 4.5.2, Debian.
|
qBittorrent version and Operating System
v4.0.2 (64bit) / Windows 8.1 6.3.9600
What is the problem
Checking completed torrent results in large amounts of the torrent being found to be incomplete. Sometimes re-checking will then find it to be complete, but re-checking again is just as likely to find it incomplete again.
This process is corrupting already downloaded torrents if a re-check is run, or if re-check on completion is set, it goes into a loop and continues to corrupt the download.
What is the expected behavior
A completed torrent should check as complete and not get corrupted.
Steps to reproduce
Re-check completed torrents.
Torrent checking stops at (for example) 58%.
Torrent begins to download again from 58%.
re-check torrent again.
Torrent check now completes to 100%
Torrent is moved to completed folder
Torrent re-checks automatically (I have that option enabled)
Re-check stops at 52% (or some other random value, but usually close to the previous value).
Torrent is moved back to incomplete folder
Torrent starts downloading
< process repeats >
Extra info(if any)
The point at which the rechecking fails seems to be random
The files which are marked as incomplete seem to be random (but seems the first file in a folder is more likely to fail)
It may only happen on Torrents where some files were marked to not download
Completed torrents are set to move to a different folder.
Re-check torrent when complete is enabled.
Some torrents were started with earlier versions of qBittorrent and qBittorrent has been upgraded since. I can't confirm if all problematic torrents were initially started with earlier versions.
Torrents are downloaded to a network share
The drive the network share is on is deduplicated. As such, size of file and size on disk are unrelated. This should not matter and I think is hidden via SMB anyway but seemed worth mentioning.
The text was updated successfully, but these errors were encountered: