How is the queue supposed to work?

Discussion of Transmission that doesn't fit in the other categories
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

How is the queue supposed to work?

Post by dskchk »

Hello,
I recently updated Transmission and now I have the queue feature. However, I can't clearly understand how it works.

I set a download queue size of 1. Then, I started a a first download and it started running. Then, I started other 7 downloads and they were queued. Fine.

After the first download has finished, I would have expected the first one of the other 7 downloads to start, with the other 6 stay queued until it is their turn.
However, what I see is that after the first one has finished, all the other 7 are started at the same time!!

Is this normal? How is the queue supposed to work?
rb07
Posts: 1400
Joined: Sun Aug 24, 2008 3:14 am

Re: How is the queue supposed to work?

Post by rb07 »

dskchk wrote:Is this normal?
No.
dskchk wrote:How is the queue supposed to work?
Just like you expected, and it works that way so something is wrong with your installation... which you didn't describe.
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

It's Transmission 2.51 on a Linux ARM NAS. I'm running the daemon and connecting through the web interface or through Transmission Remote GUI 4.0.3 (http://code.google.com/p/transmisson-remote-gui/).

The termination of the first download with the subsequent start of the following ones happened during the night, so no client was connected to the daemon at that time.

Please note that the download queue was enabled, the upload queue was disabled.
rb07
Posts: 1400
Joined: Sun Aug 24, 2008 3:14 am

Re: How is the queue supposed to work?

Post by rb07 »

dskchk wrote:the subsequent start of the following ones happened during the night
Does that mean you didn't see them start all at the same time?

I assume that is the case, then its possible that each was started alone, became "stalled", then the next started, became "stalled", and so on. That is the way its supposed to work, the key point is the "stalled" part, which you control with the setting of queue-stalled-minutes (in settings.json, different names/descriptions on the GUIs).
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

No, I didn't see them start all at the same time, so maybe it's like you said.

However, I think there's a problem here anyway. On the next morning I found all of them downloading at a good rate. Even if they were "stalled" at the beginning for half an hour (I set a 30 minutes delay to determine when a download is stalled), it's clear that after some time all of them where perfectly active at the same time... so the queue feature becomes quite ineffective, unless you disable the stalling detection or you set it to a very high delay.

I would have expected that the stalled download were paused and re-enqueued before starting the next download in the queue. Otherwise the risk to see all the queue active is high when you work with poorly spread torrents.
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

I have another question on the queue.

I had ordered my download queue in a certain way. After some days, without changing anything by myself, I find that the queue is scrambled.
Another typical case: a couple of days ago I added a new torrent and it was added as the last one in the queue. Today I find it in the middle.

I'm not sure what may have caused this. I know I've upgraded (and hence restarted) Transmission from 2.51 to 2.52, but I can't say if the queue order change is due to this or not.

Any ideas? Is the queue order supposed to survive a Transmission daemon restart?
rb07
Posts: 1400
Joined: Sun Aug 24, 2008 3:14 am

Re: How is the queue supposed to work?

Post by rb07 »

dskchk wrote:Is the queue order supposed to survive a Transmission daemon restart?
No.

There is an old ticket which reported this problem, which actually is 2 problems, I wonder why you didn´t run into the first which is that queued torrents are paused on restart (unless you are using my modified Transmission-Qt for Windows port).

The second problem is the one addressed on the ticket, the order is not preserved (and there is no fix so far correcting that one).

The issue with the order in the queue could be that after start, transmission changes the order of the torrents. The daemon loads the torrent in inverse lexical order (I think -- I´ve been trying to preserve queue order, but its too difficult with the way queues are implemented, I´m abandoning that change).
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

Following up your message, I just found ticket 4484. I didn't notice this problem because all my queue is currently made up of stopped downloads.

Instead, I can't find a ticket for the queue order not preserved problem. I found ticket 4540 but it's closed as "works for me"... Is there any other open ticket for that?

This currently is a great penalty for the queue feature actually :-(
rb07
Posts: 1400
Joined: Sun Aug 24, 2008 3:14 am

Re: How is the queue supposed to work?

Post by rb07 »

dskchk wrote:all my queue is currently made up of stopped downloads
That doesn't make sense. Queued and stopped are different states.

Yes, it was ticket 4540 the one that mentioned the order, but the report is so messed up that the ticket was closed.

Anyway neither the state, nor the order are preserved. And that is a bug, minor bug, which doesn't affect me because I'm not stopping the daemon, but people who run the application on and off are affected.
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

rb07 wrote:
dskchk wrote:all my queue is currently made up of stopped downloads
That doesn't make sense. Queued and stopped are different states.
I can't understand this. I have X downloads in my Transmission instance. They are all stopped, but they are ordered based on queue order (you can move around your downloads within the web interface, for instance, or by using a remote client). One day I will decide to start (either forcibly or by queueing) some of them (typically the first ones in the list), because I don't want to download (all of) them right now, but it's comfortable for me to have them inside Transmission, ready to start. Why shouldn't this make sense? It's perfectly reasonable for me, as it is when you use any general purpose download manager.
rb07 wrote: Anyway neither the state, nor the order are preserved. And that is a bug, minor bug, which doesn't affect me because I'm not stopping the daemon, but people who run the application on and off are affected.
Well, you will have to upgrade, sooner or later. Unless you constrain yourself to have no downloads at all in Transmission before upgrading, you'll hit this bug. And if you have a long queue, I wouldn't consider this a "minor" issue...
rb07
Posts: 1400
Joined: Sun Aug 24, 2008 3:14 am

Re: How is the queue supposed to work?

Post by rb07 »

It seems to me you are calling "queue" something else, so nothing you say makes sense. I'm talking about the state explicitly shown on some torrents, i.e. "queued for downloading". You seem to refer to the way the list is shown, which can be changed with the filters by using many different options, only one is queue order (and most torrents don't even have a queue order).

All torrents are in one state (and one only), either stopped/downloading(active/queued/error)/seeding(active/idle/stalled/queued/error)/verifying(active/queued); yes those are 2 levels of states on downloading, seeding, and verifying.

Actually is even simpler, from the code:

Code: Select all

TR_STATUS_STOPPED        = 0, /* Torrent is stopped */
TR_STATUS_CHECK_WAIT     = 1, /* Queued to check files */
TR_STATUS_CHECK          = 2, /* Checking files */
TR_STATUS_DOWNLOAD_WAIT  = 3, /* Queued to download */
TR_STATUS_DOWNLOAD       = 4, /* Downloading */
TR_STATUS_SEED_WAIT      = 5, /* Queued to seed */
TR_STATUS_SEED           = 6  /* Seeding */
And you are being silly (assuming I have no experience), of course I have upgraded, many times... but nothing was queued (everything was either downloading or seeding) so the bug didn't affect me, and hasn't affected me since the queue functionality came out for all platforms (version 2.40, 2011/10/08).
dskchk
Posts: 20
Joined: Tue Feb 16, 2010 10:22 am

Re: How is the queue supposed to work?

Post by dskchk »

I do understand that the queued state is different from the stopped state.

However, consider the web ui. Suppose you have all your downloads STOPPED (and NEVER STARTED) and the list of files is sorted by "Queue order". Look at the list with the web interface and right click on any file: you can move up, move down, move to top, move to bottom, etc..
These commands let you alter the queue order of your downloads. Said in other words, they let you define your download queue. Do you agree on this at least?

Now, suppose you select all your files and then right click on the selection and issue "Resume": Transmission will change the state of all the downloads to "downloading" or "queued to download" and will start to actually download the first ones in the queue (if you prefer, the first ones in the list!), accordingly to the queue preferences you set on the daemon. Is it ok?

Well, now suppose you have to upgrade before all the downloads are finished (or before they are all in seeding state): you will completely lose your queue (or, if you prefer, your queue order).

Now, in a different use case, suppose that, after you carefully ordered all your downloads for queueing, you don't "start" (or "resume", if you prefer) all of them, but only some, leaving the rest as stopped. This doesn't mean you don't care about the queue order of the stopped ones, because it will be important when you'll want to start them in the future. But if your carefully defined queue will get lost when you restart the daemon (because you have to upgrade, for instance, or because you have to restart the system), all your work to order the queue will be lost.

Considering that download queueing is useful when you have a lot of downloads (and not when you have just a few of them), and that when you have a lot of downloads it's quite reasonable that you may wish to add a torrent/magnet link without starting it immediately, saying that losing the queue order is a minor problem is silly for me.

If you still don't agree and still think I'm saying nonsense, just because I'm not using the words you expect, that's another story. However I do know how I'm using Transmission and any other download manager I've used so far. A queue feature that is using a transient queue order is simply an almost useless queue feature.
alakani
Posts: 1
Joined: Wed Mar 21, 2018 8:12 pm

Re: How is the queue supposed to work?

Post by alakani »

I have the same issue 6 years later on the macOS version. Why is someone with 1400 posts trying to turn the concept of a queue into an ad hominem? Fine, let's just call it "the big ol list thingy with all the stuffo in it" and get on with it.
matp
Posts: 2
Joined: Mon Feb 18, 2019 6:51 pm

Re: How is the queue supposed to work?

Post by matp »

I know this is an old one but it has come up in a few places and was bugging me as well (also here: https://www.linuxquestions.org/question ... 175573612/).

I think part of the confusion comes from calling the set of torrents to download a "queue". People think of a queue as an ordered series of things (first in first out). The reality in downloading torrents is that all that really matters are individual torrent's state (should this be downloaded if possible) and priority (which torrents should get to use the bandwidth first, etc).

If you have a list and the stuff at the top of the list doesn't have seeders...then of course we expect the stuff at the bottom of the list to download first. On the other hand if you have a ton of seeders for everything on the list, but a download bandwidth or 1Mbit...you would expect the stuff at the top of the list/queue to download first using that 1Mbit and the stuff at the bottom to only download after the stuff above it has downloaded or bandwidth becomes available because of lack of seeders.

So the idea that queue implies download order (don't download B before A) doesn't make sense in a bittorrent world I think.
However the idea that if both A and B can be downloaded, A should get a go at the bandwidth first...well that does make some sense. In this case the queue order implies a priority order in that stuff at the top should get bandwidth/download-slots first if they available.
I think this second case is where the queue randomization (or whatever it is) on transmission-daemon restart is annoying.
If I am downloading a group of files they will no longer be next to each other in the queue which makes it harder for me to visually inspect the status of things I added in a group or more vs less recently.

Maybe there is some logic to this I am missing, but I also find it quite annoying that the displayed queue (`transmission-remote --list`) is randomized when the daemon is restarted.
garcia1379
Posts: 1
Joined: Mon Mar 30, 2020 9:37 am

Re: How is the queue supposed to work?

Post by garcia1379 »

matp wrote: Tue Nov 12, 2019 5:15 pm I know this is an old one but it has come up in a few places and was bugging me as well (also here: https://www.linuxquestions.org/question ... 175573612/).

I think part of the confusion comes from calling the set of torrents to download a "queue". People think of a queue as an ordered series of things (first in first out). The reality in downloading torrents is that all that really matters are individual torrent's state (should this be downloaded if possible) and priority (which torrents should get to use the bandwidth first, etc).

If you have a list and the stuff at the top of the list doesn't have seeders...then of course we expect the stuff at the bottom of the list to download first. On the other hand if you have a ton of seeders for everything on the list, but a download bandwidth or 1Mbit...you would expect the stuff at the top of the list/queue to download first using that 1Mbit and the stuff at the bottom to only download after the stuff above it has downloaded or bandwidth becomes available because of lack of seeders.

So the idea that queue implies download order (don't download B before A) doesn't make sense in a bittorrent world I think.
However the idea that if both A and B can be downloaded, A should get a go at the bandwidth first...well that does make some sense. In this case the queue order implies a priority order in that stuff at the top should get bandwidth/download-slots first if they available.
I think this second case is where the queue randomization (or whatever it is) on transmission-daemon restart is annoying.
If I am downloading a group of files they will no longer be next to each other in the queue which makes it harder for me to visually inspect the status of things I added in a group or more vs less recently.

Maybe there is some logic to this I am missing, but I also find it quite annoying that the displayed queue (`transmission-remote --list`) is randomized when the daemon is restarted.
hello sir is your problem solved ?
Post Reply