-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable download queueing and related menu items #414
base: master
Are you sure you want to change the base?
Conversation
torrent-start to address jesec#411
7e20c35
to
d56ac3b
Compare
d56ac3b
to
da892ca
Compare
Thanks for the PR. There is a minor issue: don't touch the translations. They are handled by Crowdin. Only change I am OK with the idea. However, I think it might be more useful to have a field in
Adding a new |
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:
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. |
This reverts commit da892ca.
a6f7860
to
1931ab4
Compare
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. |
"seeding" status text for API use
1931ab4
to
e8ecf22
Compare
This is getting worse.... TorrentStatus is an array, so you can have 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. |
downloading/seeding for icons in torrent list
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. |
Great! That's what I need! Any news on it? |
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. |
some strings missing from da.json
Description
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