Force Rechecking multiple torrents can end up skipping a check in process

[Ryrynz]

qBittorrent 4.2.5 x64

Seen this quite a few times while I've been adding torrents over the last day or so, it doesn't happen all the time. If I select a couple of torrents and click Force Recheck it will start the first torrent and then move to the next one before it's finished the first. The first torrent will just sit at whatever percent it stopped at while the next one continues until finished. If I stop the checking process and just do the one torrent that stopped it checks to 100%.

[Ryrynz]

I've had this happen just now, I had two torrents in one category, while one torrent was rechecking and only at a few percent I started another recheck which was previously paused and it starts that one immediately, the first torrent keeps the status of Checking and is continued to be checked afterwards.

It doesn't happen all the time but I've just now managed to partially check a number of torrents whilst checking the first one to determine if I could interrupt the it no matter where it was in the checking process 1-99% and I could, which resulted in a number of partially checked torrents as seen below.

[xavier2k6]

can confirm that it's been there for a while.......especially if checking large torrents.....hadn't got roung to posting the issue myself...

[thalieht]

Steps to reproduce:

1. Recheck an auto_managed torrent (not paused)
2. While the first torrent is rechecking start rechecking a paused torrent

I won't mention Forced torrents because currently, they are not taken into account in the recheck queue (they are not auto_managed and no steps have been taken to make sure they are, during rechecking, so they always recheck in parallel with any other torrents).

[FranciscoPombal]

@glassez ping

[glassez]

Tested and confirmed.

For some reason libtorrent puts a (checking) torrent that has just become auto_managed at the top of the "checking" queue, thus interrupting the checking process of the previous one.
@arvidn, what's the reason of such behavior?

[arvidn]

there is just one queue, defined by the queue positions. A torrent with an earlier (i.e. lower) queue position will take priority over any torrent with a later (i.e. higher) position.

I'm pretty sure that's the behavior at least

[arvidn]

@Ryrynz on that screenshot, are torrents ordered by queue position?

[Ryrynz]

I had it ordered by status, and yes it seems only the torrents listed below the currently checking torrent when sorted by status interrupt the checking process. Sorting this way look to indeed be sorting by queue position. Does anyone care about queue position priority? I don't think anyone would want to interrupt a torrent check, these aren't exactly speedy.

[arvidn]

my understanding is that your observation supports the (what I believe is the) intended behavior of lower queue position-torrents are checked before higher queue position ones. Or that it at least doesn't contradict it. Do I understand that correctly?

[Ryrynz]

It would certainly seem that it's working as designed. Does it make sense for it to function this way?
Interrupting a check I think shouldn't happen regardless, it could be queued that way instead.

[glassez]

my understanding is that your observation supports the (what I believe is the) intended behavior of lower queue position-torrents are checked before higher queue position ones. Or that it at least doesn't contradict it.

Well, yet another related thing is rechecking completed torrents. When "force recheck" is applied to "auto_managed" torrent it gets assigned to some queue position (last position +1) so it becomes bottom in queue. But when "force recheck" is applied to paused torrent it never change its position (that is -1 for all complete torrents) so when we enable "auto_managed" for it (we do it temporarily to actually perform checking) it becomes top in queue and breaks checking of another torrent.

[arvidn]

Does it make sense for it to function this way?

I wouldn't think that adding exceptions or special cases to the simple rule that says: "only place in line determines order" necessarily is an improvement.

Interrupting a check I think shouldn't happen regardless, it could be queued that way instead.

What if the torrent that's being interrupted is less urgent than the other one?

[Ryrynz]

I understand the design, I'm just unsure many people would prefer it to function this way.
Think I'll let the devs hash it out :)

[arvidn]

I'm open to suggestions for improvements.

I believe the behavior you want is supported by the current semantics. If you want whatever torrents that are currently checking have priority, you just give them priority. I would worry that adding special cases makes it more complicated and more likely to be used incorrectly. But also that there may be use cases that are no longer supported.

[glassez]

I believe the behavior you want is supported by the current semantics. If you want whatever torrents that are currently checking have priority, you just give them priority.

So what about completed torrents? You ignored my previous comment...

[arvidn]

@glassez I would expect a completed torrent to get a queue position when you call force_recheck() on it. Is that not the case?

I would expect it to be placed last in queue (as long as it's auto-managed of course). In case it's not auto managed, it's effectively force started and will check unconditionally (at least that's my understanding).

Looking at this though, it seems like a force-started torrent that's force-checked is not assigned a queue position, but it probably ought to. because making it auto-managed later also doesn't assign it a queue position.

Is that the issue you're seeing?

[arvidn]

could someone give this a try? arvidn/libtorrent#4632

[glassez]

Looking at this though, it seems like a force-started torrent that's force-checked is not assigned a queue position, but it probably ought to.

I don't say about "force-started" case. The sequence is the following:

1. Torrent is paused (paused and not auto managed for libtorrent).
2. User call "force recheck" on it. It just resets its progress and becomes "checked" but libtorrent doesn't perforn any checking yet since torrent is still paused.
3. We temporarily resume torrent (since user expects it to be really checked). But we don't want it to be "forced" so we just apply "auto managed" on it and allow libtorrent resume it.

[arvidn]

ok. I think that patch would affect that case. I'm not sure what problems happens in step (4), but with the current logic I think the torrent would be force-checked and effectively ignore the fact that you set it to auto_managed.

With my patch, setting auto_managed will actually put it at the end of the queue and not necessarily be checked immediately

[xavier2k6]

could someone give this a try? arvidn/libtorrent#4632

Seems to be ok with the above, no skipping observed. (quick test)

@Ryrynz Can you test below build please?

qBittorrent 4.2.5 with patch for arvidn/libtorrent#4632

[Ryrynz]

Tested, confirmed fixed.

[FranciscoPombal]

Great, closing this then. This should make it to 4.2.6. Libtorrent commit: e5e2b481227a1e11317fa7a8c1f6e36140aacc65