The download queue (FIFO) behaves like stack (LIFO)

[pvelkovski]

1. Imagine that you have set the maximum number of active downloads to 4
2. There are currently 4 torrents that are being downloaded
3. You added a new torrent (5th). It should start downloading as soon as an active torrent from step 2 finishes downloading
4. You added a new torrent (6th), before any of the torrents from step 2 finished downloading. It should start downloading as soon as there is an active downloading slot available. In other words 2 out of the previous 5 torrents should have finished downloading. Under no circumstance should the torrent added in step 4 start downloading before the torrent adden in step 3.

At least that is how a download queue should work.

But it seams there is a bug in Transmission that gives greater downloading priority to the torrents that have been added later to the queue and therefore it's not a download queue anymore, but a download stack.

Because of the Bug, when you rightclick a torrent waiting for a free download slot along 3 others waiting for the same thing, and you choose Queue-> Move to Top, you expect that same torrent to be the next out of the 3 others that will start downloading as soon as there is a free download slot. Instead of this, you just made that torrent to be downloaded last.

I doubt that it is a bug that is hard to fix as it's a case of usage of a wrong data structure, Stack instead of Queue combined with inverted meaning of the "Move to top"/"Move up", "Move to bottom"/"Move down" semantics.

The most easisest way to reproduce the bug is to set the maximum number of active downloads to 2 or 3, choose View->Sort by Queue and try to download multiple episodes of some series. In this view the torrents that have priorities set with Queue-> Move to Top go on the top of the list, but end up being downloaded (actually star downloading) last.

Transmission version: 2.82 (14160)
Platform: Linux - Ubuntu 12.04 64-bit

[blacke4dawn]

Most likely related to this one: https://trac.transmissionbt.com/ticket/5298

[pvelkovski]

Might be, then again might be not. But since the ticket 5298 makes a distinction between torrent links and magnet links, I find it necessary to explain that I'm experiencing the bug I'm reporting with magnet links. By using the "Move to top"/"Move up", "Move to bottom"/"Move down" I've been sucsessful in determining the exact order of the torrents (using magnet links) to be downloaded, except they are doing opposite of what they are saying:
"Move to top" - Makes the torrent being last in the download queue
"Move to bottom" - Makes the torrent being first in the download queue
"Move up - Delays the torrent download
"Move down - Hurries up the torrent download
So in the Sort by Queue view the torrents being downloaded next are being taken from the bottom of the list displayed.

The ticket 5298 reminds me a bit of another problem I've experienced with the magnet links. Namely Transmission failed to respect the maximum number of active downloads. I was under impresson that due to "pre download phase" (getting info about the size of the torrent etc.) Transmission fails to recognize that the maximum downloading slots are filled and activtates more magnet links than it should. For example it has 2 active downloads, and it should fetch 2 more (provided you've put many torrents to be downloaded), but since it doesn't recognize the "pre download state" as active state it continues activating other magnet links. In my case with a maximum number of active downloads set to 4, it would end up downloading 7-8 distinct torrents (magnet links). Maybe I should report this too, but I'm still not certain that this happened because of the "pre download state" of magnet links or that the problem is even related to the magnet links and that it wouldn't happen if those were plain torrent files.

[blacke4dawn]

Well, if you think it's significantly different to be it's own "issue" then the best way is to report it on their trac-page.