Queue order not respected if you move torrents up or down

[eurobank]

Please provide the following information

qBittorrent version and Operating System

Qbit 4.2.1 / Windows 64 Pro

What is the problem

If you rearrange the queue (up / down / top / bottom) the queue order is not respected

What is the expected behavior

The Order # should be respected

[glassez]

If you rearrange the queue (up / down / top / bottom) the queue order is not respected

What do you mean exactly?

[eurobank]

In the capture i posted (did you checked it?) i moved the 2 to the END of the queue. And remained Downloading.

Again, it is in the capture clearly shown.

There is 1 and 4 downloading. It should be 1 and 2 downloading.

[glassez]

it is in the capture clearly shown.

Sorry, but it isn't clear. Your problem description is "If you rearrange the queue (up / down / top / bottom) the queue order is not respected". But your screenshot shows that torrents are ordered correctly.

There is 1 and 4 downloading. It should be 1 and 2 downloading.

Well. Now I see what's your real problem.
Seems queue reordering doesn't affect currently downloading torrents... @arvidn, is it intentional behavior?

[eurobank]

It is crystal clear and my topic title is not "re-arrange" but "move".

Not sure why you say it is not clear. Nothing more that i can possible provide as information.

If you manually move torrents and change the order of them, the order is not respected.

[arvidn]

are the torrents force-started? (i.e. the auto_managed flag is not set). That would explain the behavior. Otherwise, whenever the queue position is changed for a torrent, recalculate_auto_managed_torrents() is triggered, which goes through the torrents in queue order and start/stop based on that.

[glassez]

are the torrents force-started? (i.e. the auto_managed flag is not set).

According to screenshot it isn't "forced".

[eurobank]

Not forced. Auto-Managed,

[arvidn]

I could not reproduce any problems in client_test in RC_1_2. Tested with: arvidn/libtorrent#4382

Are there any other circumstances I would need to reproduce this?

[eurobank]

Well, it seems that it doesn't happen each and every time i tried it. But it happens several times.

I tend to move around files a bit, due to slow speed i currently have.

Also (if it is of any help) the problem seems to be auto-resolved if you leave it like this for a few minutes (not sure how long but less than 30). I mean that after a while, the downloading file (4rth in my capture goes to queue).

[arvidn]

The call to recalculate_auto_managed_torrents() is made regularly as well, it's just supposed to be triggered immediately when changing queue position. The default interval is 30 seconds (here). Perhaps qBT sets it to a higher value

[glassez]

it's just supposed to be triggered immediately when changing queue position.

So why it isn't applied here?
@eurobank, IIRC, you have "2 active downloads" limit configured?
It would be nice if you provide some additional info (e.g. configured limits)

[arvidn]

@eurobank does it happen when you add new torrents? or when you resume a "finished" (but not seeding) torrent?

[eurobank]

@glassez

Here are my settings:

[eurobank]

@eurobank does it happen when you add new torrents? or when you resume a "finished" (but not seeding) torrent?

No such pattern. I just sometimes re-arrange the queue.

[arvidn]

@eurobank with "Maximum active downloads" set to 1, the surprising part isn't that 2 and 3 are paused, but that 4 is started. It should be paused too

[eurobank]

@arvidn

Yes this is also a problem i always had, a different one. If the speed of the 1st is dropped below the settings for a while (192 in my case) and a second is started, it never stops even when the 1st goes above the 192 limit.

[arvidn]

this is a bit far-fetched, but it might fix some cases: arvidn/libtorrent#4385

[eurobank]

Is this fix included in 4.2.2 ?

[thalieht]

Is this fix included in 4.2.2 ?

If you mean arvidn/libtorrent#4385 then yes.

[eurobank]

ok, then it seems fixed.

[eurobank]

Sorry to say this is not solved.

[eurobank]

I have been monitoring this and after 10-15 minutes # 3 went finally into queue for some reason.

So the changes are not immediate.

[eurobank]

Even with 4.3,0 aplha i run now, still unfixed.

[arvidn]

@eurobank can you describe the behavior you see and what you would expect in some more details?

Does it happen consistently? i.e. is it trivial to reproduce? If not, can you tel if it happens under certain conditions?
Does it correct itself eventually? say, after a few minutes
Does it correct itself you you manually pause the torrents that should have been paused? (i.e. do the queued ones start then)

I have not (yet) been able to reproduce this in client_test, which is a thin wrapper of libtorrent.

[eurobank]

It is very easy to replicate, i'm seeing each and every day. REarranging the queue, bottom to top etc etc, shows clearly the issue.

Example with download rate threshold 256:

Torrent1 (queue position 1) is downloading at 400 (correct)

Torrent2 is queued (correct at queue postition 2)

Torrent3 is downwloading at constant UNDER 256 it is NOT fixed (wrong since it is at queue position 3). Continues forever. If the Torrent3 goes up from 256, then it is queued.

[arvidn]

is this issue about "don't count slow torrents" or about manually changing queue order?
Do you still experience the problem if you disable "do not count slow torrents"?

[eurobank]

I think disabling the "dont' count slow torrents" solves the issue. Not 100% sure, i will have to test more.

[arvidn]

@eurobank ok. looking back to the initial report again, I don't see what the problem is. You have "maximum active downloads: 1"
and you have "don't count slow torrents", a slow torrent is one that downloads slower than 256 kiB/s.

In your screen shot, you have one downloading torrent, the one at queue position 1. This is correctly ordered, that's the one that's supposed to be downloading. Then you have a slow torrent, which isn't subject to the limits, so it will keep downloading.

Would you expect the slow torrent to be paused? If so, why?

[eurobank]

@arvidn

Ok, if this:

looks correct in your eyes, then what else can i say.

Anyways this is a small problem and this issue is getting hairy, so ....

[arvidn]

so is it the presentation in the UI that's the problem? would you expect slow torrents to look different?

The reason I ask is because me personally is mostly concerned with the core functionality, and right now this ticket is labeled "core" and "libtorrent", but now it sounds like perhaps "GUI" would be better after all.

[eurobank]

@arvidn

What is a correct QUEUE? Does the (1) (2) (3) (4) (in my case above) means some kind of priorities or NOT?

How can N1 be active, N2 and N3 be queued and N4 active?

Maybe i got the whole "queue" thing wrong? Is that an issue of your lib or Qbit?

[arvidn]

What is a correct QUEUE? Does the (1) (2) (3) (4) (in my case above) means some kind of priorities or NOT?

It's the order in which torrents are considered to use up the active-limit, active-downloading and active-seeding limits.

How can N1 be active, N2 and N3 be queued and N4 active?

not all torrents are considered for those limits. force-started torrents is another example.

Maybe i got the whole "queue" thing wrong? Is that an issue of your lib or Qbit?

Well, I think it depends on what the issue turns out to be. I see it can be:

• libtorrent documentation issue
• libtorrent behavior is non-sensical and should change
• qbt presentation is confusing
• qbt settings are unclear

[glassez]

if this looks correct in your eyes, then what else can i say.

If your settings are:

1. Max active downloads is 1
2. Don't count slow torrents in limits
3. Torrent nr.4 is "slow" according to your settings

then everything looks correct.
You have 3 torrents that are managed by "queue" and 1 active torrent (torrent nr.1, that is correct).

[eurobank]

@glassez

How do you know the queued 2 and 3 should not be active? And that 4 is slow? How do you know 2 and 3 aren't also slow?

Guys, sorry but this is not the way a queue works. You will make me forget the basics.

This is not the way all torrent clients work, this is unique to Qbit. And a wrong logic.

[arvidn]

How do you know the queued 2 and 3 should not be active?

because they are at the 2nd and 3rd position in the queue, and you only have 1 active download, so only the first in the queue is started.

And that 4 is slow?

Its download rate < 256 kiB/s (per your settings)

How do you know 2 and 3 aren't also slow?

It doesn't matter whether they would be slow if they were started. They are queued so they're not started.
The "don't count slow torrents"-feature doesn't optimistically start every torrent periodically just to see if they are slow or still fast. It prevents torrents from stopping.

[arvidn]

Guys, sorry but this is not the way a queue works. You will make me forget the basics.

Let's say slow torrents, instead of having their queue position preserved, are somehow moved to the bottom (or the top) and they don't have a queue number. That way the "queue order" would match the "started order" to some extent. I don't know if this is what you envision, but if the slow torrent becomes fast, and it's queued. What position in the queue should it get?
Presumably you would want it to move back to where it was. As if it never lost its place in line in the first place. That's the rationale for the current behavior.

This is not the way all torrent clients work, this is unique to Qbit. And a wrong logic.

When asked "what behavior do you expect?" it's a perfect opportunity to explain how you think it should work, and if other clients work the way you describe. It would be great to also give some rationale for why you think an alternate behavior is better.

I'm quite serious, I'm open to be convinced that there are better behaviors.

[eurobank]

@arvidn

If the max concurrent torrents is ONE, then if the N1 is ABOVE the "slow" limit, then ONLY one torrent should be active. No other should start (and they DO start for some reason).

If i move the last queued torrent to the top, it should be started and ALL other paused/queued. If the N1 drops below the slow limit, then the N2 should be started and so on, until the max torrents are reached.

[eurobank]

An other scenario:

Two torrents. The N1 is slow and the second is started also. Correct.

As some point the N1 is NOT slow anymore. Should the N2 continue or not?