add a "trust me, it's all at 100%" option to skip the data check for seeding

[jbruchon]

I recently had to remove and re-add a 120GB torrent that I created and that I'm seeding. When I point the re-loaded torrent to the data folder containing the data, all the data is re-checked. I'd like the ability to skip this re-check and tell the program that all the data is fully intact and at 100% completion.

[as-muncher]

There's definitely an issue, where if I defragment the hard drive using Windows Defragmenter, and also change the MAC address for my computer, then qBittorrent wants to check a lot of my torrents.

[stalkerok]

There's definitely an issue, where if I defragment the hard drive using Windows Defragmenter, and also change the MAC address for my computer, then qBittorrent wants to check a lot of my torrents.

Disks need to be defragmented when no other file manipulation is happening (with qBittorrent closed), that's obvious, and the MAC address can have nothing to do with it.

[glassez]

qBittorrent is supposed to check files (namely check data hashes) in the following cases:

1. When you initially add a torrent and there are corresponding files on the disk (the ones with matching paths).
2. When you start a torrent that still hasn't checked files (or didn't complete the check the previous time, so it continues it). The same applies to the case when you resume a session that has unchecked (incompletely checked) torrents.
3. When you manually trigger "force re-check".
4. When you move a torrent to a location that already contains the corresponding files.
5. When a torrent added previously in the "seed mode" encounters an incorrect piece when sending to peer (in this mode, the torrent checks each piece when it is first sent to peer, and if it fails, it leaves the "seed mode" and starts checking the entire torrent).

[glassez]

Note that you should not confuse the "checking" state (i.e. checking hashes) with the so-called "checking resume data" (when a torrent just checks for the presence of files on the disk and their sizes).

[glassez]

It seems that qbittorrent is not saving its status as often as it should be. qB should save its progress every few seconds if not every second or continually.

It does. qBittorrent saves torrent states at some key events and during app shutdown. There is also a periodic saving, the interval of which you can set in the settings.

[as-muncher]

@glassez Thanks for your comments, but honestly, I find that qbittorrent starts checking torrents for seemingly no reason. I wish I could nail it down for you. Sometimes, I've wondered if it's when I change my computer's mac address to a specific one that's causing it, or if it's a combination of defragmentation and entering or exiting airplane mode, or if I'm connecting to a different network, or what. But I can understand the original poster's frustration, because it could be that that torrent with hundreds of GB of data, could be checked by qbittorrent for seemingly no good reason (not just checking resume data).

[glassez]

Unfortunately, your comments are quite confusing, inconsistent, and do not provide enough necessary details for me to move forward in researching this problem. E.g.:

if I defragment the hard drive using Windows Defragmenter, and also change the MAC address for my computer, then qBittorrent wants to check a lot of my torrents.

...does not provide any information about the sequence of actions and events.

Also there are no logs, no screenshots linked to specific described actions and events...

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

Doesn't the "skip hash check" checkbox in the add torrent dialog achieve what you want?

i had to scroll too much for this.. i just wanted to re-add the torrents back to qbittorrent and this is the right answer

[jbruchon]

Doesn't the "skip hash check" checkbox in the add torrent dialog achieve what you want?

i had to scroll too much for this.. i just wanted to re-add the torrents back to qbittorrent and this is the right answer

It's not the right answer if you have 2000.existing torrents that decide to do full rechecks after a crash.

[HanabishiRecca]

I think we need more actual logs here. Is there any errors when this happens?

Building libtorrent with verbose logging enabled (TORRENT_DISABLE_LOGGING=OFF cmake flag) also could help. It would be a bit noisy, but could bring some light to what actually happens under the hood in case of failure.

[HanabishiRecca]

Also 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.

If you find yourself in "missing files" state for some reason (for example, you forgot to connect the external drive where the torrent contents are stored), then qBittorrent will not lose existing progress

I can confirm that on current master with libtorrent 2.0.10. Started the client with the drive unmounted => all torrents are in "Missing files" state. Mounted the drive back, restarted the client => everything is fine again, no rechecks triggered.

[lukefor]

I can confirm that on current master with libtorrent 2.0.10. Started the client with the drive unmounted => all torrents are in "Missing files" state. Mounted the drive back, restarted the client => everything is fine again, no rechecks triggered.

To hit the bug you need to restart the client during 'checking resume data'. If you let the client start fully and stop gracefully it will not occur. It is easier than it sounds to hit as drives being unavailable usually goes hand in hand with many reboots/restarts to get things up and running again, and if you have thousands of torrents the client can take minutes to fully start

[HanabishiRecca]

If you let the client start fully and stop gracefully it will not occur.

Yes, it was about the graceful scenario. It actually used to trigger rechecks too in the past.

To hit the bug you need to restart the client during 'checking resume data'.

Yeah, I have seen that already reported. I guess there is some race condition happening when the client wraps up and shuts down at the same time.

But there is also another problem related to unexpected power loss / process kill. Technically it should not trigger rechecks afaik. If you have a large amount of active torrents, which leads to resume data being written to the disk effectively all the time, I could see how it could lead to data corruptions.

Btw, switching Resume data storage type to SQLite database may help with that particular issue.

[stalkerok]

To hit the bug you need to restart the client during 'checking resume data'.

I can't confirm. No matter how many times I try to get this behavior, the client starts up as normal. For reference, I have ~4000 torrents in my client, totaling over 50TB, which means that the client does not start immediately.

[glassez]

To hit the bug you need to restart the client during 'checking resume data'.

I can't confirm. No matter how many times I try to get this behavior, the client starts up as normal. For reference, I have ~4000 torrents in my client, totaling over 50TB, which means that the client does not start immediately.

FYI, I finally managed to reproduce it and figure out what its cause is. More details in #21775. Should be fixed by #21784.

[smiba]

That's great news! Honestly I'm quite surprised this actually ended up being a genuine bug, as I believed it was user error.

My apologies to @jbruchon for insisteing it likely was

[ElDavoo]

Well done! Let's see how next release turns out.