Enable download queueing and related menu items

[FinalDoom]

some strings missing from da.json

Description

• Changed Transmission to use "start" on torrents, added a new context menu "Start Now" that uses start-now, which bypasses download queues.
• Separated download-queued torrents from downloading in status reporting (and respective seeding equivalent)
• Added visible-if-non-empty Queued filter under Downloading and Seeding in sidebar
• Added Queued icon (filled hourglass right now, but kinda crappy compared to existing icons, just ported from material-icons)
  • I also like this as a "clock" icon, but hourglass seemed to fit the style a little better
  • Queued icon also used in torrent list to indicate downloading but queued (hourglass rather than play button, green)
  • All this could be duplicated/modified slightly to also respect seeding queue reporting

Related Issue

I opened #411 and #413 , both of which should be addressed by this. I tried to separate them (first commit addresses just #411), but in the end they're pretty interrelated.

Types of changes

• Breaking change (changes that break backward compatibility of public API or CLI - semver MAJOR)
• New feature (non-breaking change which adds functionality - semver MINOR)
• Bug fix (non-breaking change which fixes an issue - semver PATCH)

• Non-breaking change introduced to /api/torrents/start, optional "force" parameter, which only Transmission uses right now. Nothing else should care
• I consider Start command for Transmission client executes "Start Now" command, skipping download queue #411 a bug, as the queue is in place with good reason. Starting 100 torrents quickly overwhelms filesystem and tcp / ethernet adapter kernel limits and breaks things.. queueing helps prevent that (though you can still override it with start now)

[jesec]

Thanks for the PR.

There is a minor issue: don't touch the translations. They are handled by Crowdin. Only change en.json.

I am OK with the idea. However, I think it might be more useful to have a field in TorrentProperties that indicates the position in queue, instead. We can call it position or queued, and the value could be:

• null - there is no queue
• -1 - force active, queue ignored
• number - position in queue, 0 means current active

Adding a new status could have unintended effects, especially when other statuses are replaced by it in some cases. For instance, API users like Sonarr could be looking for torrents with a specific status like downloading or seeding. Some clients also allow queue for both leeching/seeding, and it would be useful to know which queue is the torrent on.

[FinalDoom]

Gotcha, I'll remove the other translations. There's some keys missing from de or one of the nordic ones, fyi.

I agree, it could be useful to report/enable manipulation of the queue position. However, that would be a lot more effort than I was looking for to expose.

I'm not sure what you mean by API users RE statusing? Does the flood packaged with transmission et. al. act as a proxy between those clients and Sonarr? As far as I'm aware, those just directly interface with the RPC, same as flood does.

There are two queue statuses returned by Transmission, for downloading and seeding respectively. I don't use seed queueing, so I didn't add it, but it would be an equivalent set of changes, just with a "queued-downloading" and "queued-seeding" or "queued","downloading" or whatever. It is a separate status id, flood was just combining the download queue and downloading statuses.

Edit:

I checked Sonarr and it does have a flood connector. Interesting. Didn't realize that meant this Flood. I think I get what you're going for, and without looking into Sonarr's interface, it sounds reasonable. I'll poke at it later.

Looks like sonarr is just looking for names in the list of statuses. I think just restoring the prior statuses and basing the new menu filter on downloading&&!queued + downloading&&queued would work and not break things dependent on the API. See Sonarr's handling:

                if (properties.Status.Contains("error"))
                {
                    item.Status = DownloadItemStatus.Warning;
                }
                else if (properties.Status.Contains("seeding") || properties.Status.Contains("complete"))
                {
                    item.Status = DownloadItemStatus.Completed;
                }
                else if (properties.Status.Contains("downloading"))
                {
                    item.Status = DownloadItemStatus.Downloading;
                }
                else if (properties.Status.Contains("stopped"))
                {
                    item.Status = DownloadItemStatus.Paused;
                }

I'll look at handling the queue positions as a separate effort. It feels kinda pointless without a way to manipulate them in the UI. E.g. a queue position column in the queue view, and context menu items move up/down/top/bottom in the queue view or something. It might be more complex than it's worth to restrict to the queue view really.

[FinalDoom]

I set the statuses back to include the original values, and added a "downloading-queued" and "seeding-queued" state. Sonar et. al. should behave the same.

Unfortunately, queue position is not usable on its own to differentiate queued vs non-queued. It's a value 0..n that roughly corresponds to added order unless otherwise manipulated.

Unless flood stores a computed value at status fetch time, you won't get -1, null, etc. like suggested. I don't know that that's desirable either anyway, as you're losing information in that action. It's also rather tedious to have a computed value based on status and queue position and client settings where there can just be a more fine-grained status. Until that info is exposed in API I don't know that it's worth it. I believe other clients have a similar statusing/queue enumeration as well, but it's been a while since I used any of the others.

[jesec]

This is getting worse....

TorrentStatus is an array, so you can have downloading and queued in it. We definitely don't need a downloading-queued, and other hacks.

Transmission does not have it, but Flood's backend can do that transformation. It can utilize all the info fetched from the Transmission, and then process it to the one expected by the frontend.

[FinalDoom]

The different types of queued status are simplicity in the sidebar filter, counts, etc. With both seeding and downloading queueing enabled, you'd be storing combined counts. There's already an overlap that makes computing counts arduous with them separate. It'd be worse with them combined.

I'm still not sure I see the value in a computed queue position either way. You want to query the server for its queue enabled/disabled (different query from torrent-get) + position + status to compute a position for every torrent? Plus "force active" isn't an ongoing state, that's a one-time action and couldn't be calculated from a RPC query. If you're looking for it to indicate Transmission's settings, a better way to expose that would be to actually expose the settable/gettable settings for the whole client, not per torrent.

[imseon]

Great! That's what I need! Any news on it?

[FinalDoom]

The news for me is I'm not going to update this without further guidance/rationale from the maintainer, which he doesn't seem interested in providing.

Depending on your target deployment, you can just mimic 331f71f in the deployed code to respect your existing Transmission settings.