Skip torrent checking after relaunch

[TheYMI]

Suggestion

When launching qBittorrent, any torrents that weren't fully checked before it was closed require a recheck, which consumes a lot of time and resources. This process should be allowed to be skipped.

Use case

After installing v5.0.1, changing some configurations that were reset after the version change required a relaunch of qBittorrent.

Since I have over 4k torrents, not all of them were updated before I closed the client. After launching, it started checking all the torrents that weren't updated. That's thousands of torrents - several TBs worth of data - some of which are on a NAS. This will take days, if not over a week, without me changing any of the files and the recheck being completely unnecessary.

During this time my network is completely clogged, my NAS is unusable and those torrents are not seeding. THIS NEEDS TO BE FIXED NOW!!! (a workaround is also okay)

Extra info/examples/attachments

Closing 21766 as a duplicate of something that's been ignored for over a decade isn't a solution. I will keep reopening this issue until someone actually takes it seriously instead of sweeping it under the rug.

[HanabishiRecca]

I will keep reopening this issue until someone actually takes it seriously instead of sweeping it under the rug.

Then you simply will be banned.

THIS NEEDS TO BE FIXED NOW!!! I need a solution.

This is your problem. You are not in a position to demand anything.

qBittorrent is a free and open source software developed by volunteers in their free time. You don't pay for it, you use a product of other people's free will. Noone would rush solving your problems and implementing your wishes, especially if you ask for it disgracefully.

Maybe you want to do it yourself? PRs are welcome.

[TheYMI]

I will keep reopening this issue until someone actually takes it seriously instead of sweeping it under the rug.

Then you simply will be banned.

Users on GitHub are free to make.

THIS NEEDS TO BE FIXED NOW!!! I need a solution.

This is your problem. You are not in a position to demand anything.

Nope. There are complaints about this issue since 2012. I'm the last one, not the only one.

qBittorrent is a free and open source software developed by volunteers in their free time. You don't pay for it, you use a product of other people's free will. Noone would rush solving your problems and implementing your wishes, especially if you asking for it disgracefully.

People have been asking nicely for YEARS. No solution or workaround has ever been offered. Closing my issue as a duplicate of a 12-years-old unresolved issue while shrugging it off is also disgraceful. The issue is the result of a problematic behavior that's been known for years, and no one ever cared enough to solve. There's probably a list somewhere that could be cleared with a single button click, if you just know the piece of code that checks it. Might even be a file that could be edited as a workaround, but even that was never offered.

So yes, I was very annoyed when I opened this issue, because my search for a solution before coming to GitHub gave me nothing other than years-worth of frustrated people complaining about this behavior, with developers disregarding them. And while this is a free product, if it's causing me problems (e.g. high usage of my network and overworking my NAS) when I used it as intended due to negligence, then yes, I feel like I'm owed a response from the developers.

[HanabishiRecca]

Users on GitHub are free to make.

And repo owners are free to ban anyone from it.

Nope. There are complaints about this issue since 2012. I'm the last one, not the only one.

You are the one demanding a solution right now.

Closing my issue as a duplicate of a 12-years-old unresolved issue while shrugging it off is also disgraceful.

But it is, objectively, a duplicate. Belive me, keeping around 1000 issues for the same problem would not help fixing it faster.

People have been asking nicely for YEARS. No solution or workaround has ever been offered. The issue is the result of a problematic behavior that's been known for years, and no one ever cared enough to solve. There's probably a list somewhere that could be cleared with a single button click, if you just know the piece of code that checks it.

Exactly. Years of asking instead of proposing a fix. If you think it's so easy, why you would not just go and fix it?

But I doubt it, as you don't even understand that the problem's roots are not even really in qBittorrent code in the first place, but grow deeply from libtorrent behavior.

If you think about it for 1 second, you might realize that if there was an easy fix, it would have been fixed already. And there wouldn't been pages of discussion around it.

if it's causing me problems (e.g. high usage of my network and overworking my NAS) when I used it as intended due to negligence, then yes, I feel like I'm owed a response from the developers.

No, you don't. Read the license.

  15. Disclaimer of Warranty.

  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

[glassez]

Since I have over 4k torrents, not all of them were updated before I closed the client.

What do you mean by "updated"?

Nope. There are complaints about this issue since 2012. I'm the last one, not the only one.

About what issue exactly?

Some explanations (that I have already made repeatedly in other similar topics)

If you've started "rechecking" torrent, then you can't just cancel it to get back to the previous state. "Recheck" literally means "forget the current progress and start a torrent from scratch." (Of course, you can stop the torrent being checked and then start it again, just like any other.)

Due to the peculiarities of libtorrent's behavior, qBittorrent used to really sin by unexpectedly starting a "recheck" in various situations and it caused a lot of inconvenience for users, and everyone agreed with that. I am someone who has been struggling with these issues for a long time (as reports of similar circumstances in which it behaves this way appear). And I believe that I have fixed them all. (At least it is incorrect to refer to those old issues in relation to the current qBittorrent.) Now qBittorrent does not start rechecking by itself under almost any circumstances (there is one, but it hardly relates to your problem, this is when moving the torrent to a new location where there are already matching files). Since then, no one has provided confirmed data on any other circumstances in which qBittorrent can spontaneously start "rechecking" torrents. So the only known way to start "rechecking" at the moment (apart from the one mentioned above) is if the user does it himself.

[TheYMI]

I started the client. All torrents start as "Checking resume data". I closed the client while most checks haven't finished. I relaunched the client, and everything whose status was "Checking resume data" before I closed the client, now requires checking.

[HanabishiRecca]

Yeah, we actually struggle to reproduce that. https://github.com/qbittorrent/qBittorrent/issues/13556#issuecomment-2367526735

[glassez]

I relaunched the client, and everything whose status was "Checking resume data" before I closed the client, now requires checking.

What do you mean by "requires checking"? To avoid confusion with the terms used, it is better to accompany them with screenshots. And it would be extremely useful to take a look at the latest logs.

[TheYMI]

Things that are checking resume data (blue) when closed, require checking (red) after relaunch. Seeding torrents (black) do not require recheck.

I did notice that not everything requires a recheck (red) if it was checking resume data (blue) when the client was closed. This seems to be true for files that were recently rechecked (red) and no longer require a check (black). From an investigation I conducted, it seems like the decision is related to the contents of the .fastresume files in the BT_backup directory.

[TheYMI]

I created a small python script (for Windows) that works as a workaround to this issue.

[TheYMI]

Exactly. Years of asking instead of proposing a fix. If you think it's so easy, why you would not just go and fix it?

Done (although it's a workaround and not exactly a fix).

But I doubt it, as you don't even understand that the problem's roots are not even really in qBittorrent code in the first place, but grow deeply from libtorrent behavior.

If you think about it for 1 second, you might realize that if there was an easy fix, it would have been fixed already. And there wouldn't been pages of discussion around it.

Was pretty easy once I looked at the code for 30 minutes to understand where the decision comes from. Then another 30-ish minutes to compare a .fastresume file before and after the check. About 10 minutes to write a few lines of code that simulate the change and check if it fixes the issue and another hour to clean it up and write a decent looking script that does the same to all files, as well as running a test to make sure I don't break anything.

Imagine the wonders I could do if I knew the codebase well enough to integrate it into the code and add a GUI element that evokes it.

[TheYMI]

In all seriousness, I don't feel confident enough to convert it into C++ and adding it properly. Feel free to take my code and use it to add this as a feature (the code is simple enough to understand, but I'd be happy to answer any questions).

I would add it as a button as suggested in the title of 13556, and then add a confirmation prompt that requires another approval with a disclaimer. Additionally, I completely closed qBittorrent while running the script to avoid editing files that might be in use. If this is implement within qBittorrent, I would make sure to stop all activity and release all file handles before changing the files' contents. Then I would relaunch qBittorrent to start the startup process to reload all the torrents from scratch. My script keeps a backup of the files I'm changing, but the disclaimer in the confirmation window should probably advice the user to copy the whole BT_backup directory as backup while qBittorrent is closed before proceeding.

[TheYMI]

Yeah, we actually struggle to reproduce that. #13556 (comment)

I was able to reproduce it (on Windows) by closing qBittorrent, creating a lockfile in AppData\Local\qBittorrent, relaunching qBittorrent and then closing it again. It wasn't as bad as I had it earlier, but I did get ~900 torrents to require an unnecessary recheck.

My script managed to fix it again.

EDIT: Launching qBittorrent, changing a configuration and immediately closing and launching it again had a similar effect, with less torrents (~40). My guess would be that something interferes with the update of the .fastresume file writing, and the files that don't get updated require another recheck. I also noticed that closing qBittorrent is way faster when the issue reproduces, further reinforcing my suspicion that file writing is skipped for some reason.

[HanabishiRecca]

Done (although it's a workaround and not exactly a fix). If this is implement within qBittorrent, I would make sure to stop all activity and release all file handles before changing the files' contents.

Unfortunately, you didn't discover anything new here. Of course we could simply reset the state of torrents. And we don't need to edit the files in such dirty way. We can just change the state inside the client.

Although, as you already pointed out, this is not a fix, this is a workaround. I'll quote myself from https://github.com/qbittorrent/qBittorrent/issues/13556#issuecomment-2366894832:

I think "trust me" button would only mask the symptoms. And still requires significant manual user intervention, which is not good. It would be better to fix the root problem instead.

I.e. "trust me" button is a slippery slope. If this situation happened, it means something went wrong. And if something went wrong, the data could be corrupted. Giving users access to such button could lead to abuse with catastrophic consequences. E.g. "oh, my torrent is not 100%, I guess I just hit that button".

A proper fix should prevent this situation from happening.

My guess would be that something interferes with the update of the .fastresume file writing, and the files that don't get updated require another recheck.

It is likely. Again, quoting myself from https://github.com/qbittorrent/qBittorrent/issues/13556#issuecomment-2366910223:

I guess there is some race condition happening when the client wraps up and shuts down at the same time.

I highly recommend you to read the whole conversation. There are lot of insight from qBittorrent and libtorrent devs.

---

P.S. Make a regular backup of your BT_backup folder. Things could go wrong, files could be corrupted to the point of no return or deleted.

Switching Resume data storage type to SQLite database is also an option. It doesn't seem to help from this issue specifically, but should be more resilient in theory. You would have a single torrents.db (and a bunch of WAL files while the client is running) instead of .fastresume files.

[HanabishiRecca]

I was able to reproduce it (on Windows) by closing qBittorrent, creating a lockfile in AppData\Local\qBittorrent, relaunching qBittorrent and then closing it again. It wasn't as bad as I had it earlier, but I did get ~900 torrents to require an unnecessary recheck.

This experiment is actually interesting. I wonder if that happens when user somehow manages to launch multiple client copies on the same profile.

Could you try to switch Resume data storage type to SQLite database and check if you are able to reproduce the problem? Make backups before experimenting of course.

[glassez]

From an investigation I conducted, it seems like the decision is related to the contents of the .fastresume files in the BT_backup directory.

Could you reproduce the issue so previously completed torrent become "unchecked" and provide me its .fastresume file (ideally two variants of it, one copied before experiment and one after torrent becomes "unchecked") for investigating?

[glassez]

Although, as you already pointed out, this is not a fix, this is a workaround. I'll quote myself from #13556 (comment):

I think "trust me" button would only mask the symptoms. And still requires significant manual user intervention, which is not good. It would be better to fix the root problem instead.

I.e. "trust me" button is a slippery slope. If this situation happened, it means something went wrong. And if something went wrong, the data could be corrupted. Giving users access to such button could lead to abuse with catastrophic consequences. E.g. "oh, my torrent is not 100%, I guess I just hit that button".

👍

[glassez]

I was able to reproduce it (on Windows) by closing qBittorrent, creating a lockfile in AppData\Local\qBittorrent, relaunching qBittorrent and then closing it again.

What lockfile do you mean? Just a regular file with name lockfile?

[glassez]

I created a small python script (for Windows) that works as a workaround to this issue.

It looks doubtful... What do you think it's supposed to do? IIRC, it can only mark all the pieces as "checked", but it cannot restore previous progress if the torrent was (partially) downloaded earlier. So I'll repeat it again. The only correct solution would be to try to find the reason for the loss of progress and fix it, rather than invent dubious workarounds.

[TheYMI]

I managed to reproduce the issue (on Windows). Here are the steps:

1. I copied the whole BT_backup directory while qBittorrent is running
2. I closed qBittorrent and waited for it to completely shut down
3. I created a regular file named lockfile at AppData\Local\qBittorrent with no content and no extension (similar to the one qBittorrent creates once it starts running) using touch from Git Bash
4. I launched qBittorrent and immediately closed it
5. I launched it again and after startup, I had ~750 torrents that required recheck
6. I found one of the torrents and used its Info Hash v1 to identify the .fastresume file
7. I copied the original file from the copy I created (_orig) and the same file from the active BT_backup directory (_after)
8. I uploaded them both here (I added .txt to the name so GitHub will let me upload them, but I didn't open them or changed their content)

Something that could be of interest: I failed to reproduce the issue multiple times when I tried to do so while a torrent was downloading. Once it finished, I managed to reproduce on my first try.

Files: f6e77c00ba3d8bc4dc1f8089333ba1da1a13e3c9_after.fastresume.txt f6e77c00ba3d8bc4dc1f8089333ba1da1a13e3c9_orig.fastresume.txt

[glassez]

4. I launched qBittorrent and immediately closed it

Could you still provide a log of this run?

[glassez]

3. I created a regular file named lockfile at AppData\Local\qBittorrent with no content and no extension (similar to the one qBittorrent creates once it starts running)

Are you sure? IIRC, qBittorrent creates lockfile at AppData\Roaming\qBittorrent (at least in my system).

[TheYMI]

3. I created a regular file named lockfile at AppData\Local\qBittorrent with no content and no extension (similar to the one qBittorrent creates once it starts running)

Are you sure? IIRC, qBittorrent creates lockfile at AppData\Roaming\qBittorrent (at least in my system).

Sorry, you are correct. I created it in the correct location (Roaming), but copy pasted the wrong path to my reply.

4. I launched qBittorrent and immediately closed it

Could you still provide a log of this run?

I'll have to check if I can find it. I restarted the client multiple times and the log rotates each time, so I'll have to see if I can find the correct one.

[glassez]

Well, I managed to reproduce it by slightly modifying the libtorrent code by adding a delay during resume data checking. Working on it...

[glassez]

Well, I managed to reproduce it by slightly modifying the libtorrent code by adding a delay during resume data checking. Working on it...

21784

[as-muncher]

Oh my gosh, finally. I didn't have all the data that I could post for this issue, but this problem has been happening on my system, very annoyingly. Thank you @TheYMI and @glassez. You'd think that qbittorrent would not delete all the data about the torrent before it started its check, and there were a lot of unnecessary checks anyways. This finally looks promising.