Unable to force recheck or resume in qBittorrent 4.1.0

Windows specific questions, problems.
Post Reply
lev

Unable to force recheck or resume in qBittorrent 4.1.0

Post by lev »

Please see https://github.com/arvidn/libtorrent/issues/3134

trying to track down this issue - seems like it has been reported previously https://github.com/arvidn/libtorrent/issues/169

Arvidn is requesting additional information from logs: 

set the alert_mask to all set bits. https://libtorrent.org/reference-Settin ... alert_mask

I dont see where qBittorent exposes the alert_mask as a configurable setting. Can it be passed as a command line option or is there a debug version which allows this configuration?
Last edited by lev on Mon Jul 16, 2018 4:39 am, edited 1 time in total.
Jack_K

Re: Unable to force recheck or resume in qBittorrent 4.1.0

Post by Jack_K »

Hi,

I got the exact same issue you describe, several times. From qbitorrent 3 (before) and 4 too.
I have lost around one hundred of seedings because of that.


I’d like too add my understanding of the problem.
I repeat how to reproduce it:

Start qbitorrent while the location of the files is unavailable.
(that’s pretty much all!)

This cause my files (some of them, [randomly, proportionally to how long qbitorrent stay open with file's location unavailable] )  that are at 100% downloaded and seeding (some times for months), to get stuck in checking and rechecking for ever.
It's some kind of corruption of the file ".fastresume" in the folder BT_backup . Their are not even suppose to be checking. They should just start seeding again, being at 100% download (in reality, but not for the qbitorrent anymore).
The downloaded files themselves are perfectly normal, unmodified by the problem, by the corruption of the of file ".fastresume".

I checked by restoring a backup I had of the file .fastresume of a torrent. And the torrent was back as it was at the date of the backup. Everything was fine again.


I’d like to propose a workaround. It doesn’t fix the cause, but fix the effect:

qBitorrent could make a backup of the folder BT_backup when shutting down. In the settings we could define how many backup we wish to have. 1 as a default is fine I think.
Then,  when we do a right click on a torrent, having the option: “restore fastresume file from backup”.
(Or better, but harder: qBitorrent detect the checking loop, and restore it automatically.)
This fairly simple solution would be wonderful. While fixing the cause would probably take a tremendous amount of time (if even possible at all). This workaround would not.



Jesus, if someone could help with that. It's a problem that's been around for years. And it's quite ridiculous too look at. Just as much exasperating. The files are just fine, but can't resume!

Thanks for anybody that would help.

(I edited after my "finding" on the fastresume file)
Last edited by Jack_K on Fri Aug 10, 2018 1:18 am, edited 1 time in total.
lev

Re: Unable to force recheck or resume in qBittorrent 4.1.0

Post by lev »

Thanks for adding that information.  I could not reproduce my issue on qBittorrent v3.3.16 so I am still using that version for now but I know eventually I will have to upgrade for a security fix or something so I hope to help address the issue by providing additional information.  Logging the problem seems to be the place to start, but I guess you have to be a developer to get to those log settings Arvidn mentioned.  ???
Last edited by lev on Tue Aug 14, 2018 6:12 pm, edited 1 time in total.
Jack_K

Re: Unable to force recheck or resume in qBittorrent 4.1.0

Post by Jack_K »

As mention previously, I have no hope for a fix.

I personally put my "workaround solution" to work. It's not integrate to qBittorrent the slightest, but that all I have for now, and it works. I use my prefer backup software, and schedule an automatic backup (of the folders concerns) when the computer start, before qBittorrent start.
So I'm safe from now on to have to face such problem.

I recommend to do the same to people who have their torrents on external drive or any other type of storage that could be unavailable by mistake or whatever else.


PS: for information, my "BT-backup" folder contain 563 torrent files and 563 fastresume files, for a total of 53MB . So, backup is fast and easy.
Last edited by Jack_K on Wed Aug 29, 2018 9:11 am, edited 1 time in total.
Shadowhwk
Newbie
Newbie
Posts: 4
Joined: Tue May 14, 2019 7:25 pm

Re: Unable to force recheck or resume in qBittorrent 4.1.0

Post by Shadowhwk »

I'm new to the forum but have logged issue https://github.com/qbittorrent/qBittorrent/issues/10640 on Github.

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.
Post Reply