[Feature request(s)]: override baseURI / other bits

[mpmc]

Big thanks to @ikatson (& contributors) for writing rqbit. It has to be one of the nicest clients I've tried, 8.0 is a great release!

I have a few feature requests & suggestions :).

• Add an option to override the HTTP base/playlist URI (having this option would allow easier proxying via nginx/etc).
• The API on its own path (similar to the above I suppose).
• Magnet editing on "add from magnet" dialog for (adding trackers etc), similar to https://madeby.lynx.pink/magnets/.
• Add SystemD unit to docs. [I wrote my own (horrid IMO) service file here.
• (Some) Configuration via Web UI. This one might be an issue as certain settings shouldn't really be changed this way and it adds more cruft :(.

[ikatson]

Thanks @mpmc for kind words!

I don't see any downsides in doing the first 2 (baseURI), proxying rqbit's API sounds reasonable. We may keep the issue around just for these, they shouldn't be hard to add.

Below are comments / questions on others

Magnet editing on "add from magnet" dialog for (adding trackers etc), similar to https://madeby.lynx.pink/magnets/.

Could you elaborate on the use case here? For example, do you primarily want to add trackers manually? If so, that's already possible via the API, and exposing it in the UI wouldn't be too hard. However, a full-fledged magnet editing feature would be more complex. What specific features, aside from adding trackers, do you think would be valuable here?

Add SystemD unit to docs. [I wrote my own (horrid IMO) service file here.

Your file actually looks fine to me! It's clear and functional. That said, it seems very tailored to your specific setup. Adding an example SystemD unit file to the docs might not be universally helpful, as most users with the knowledge to create a unit file would already know that "rqbit server start" is the key command. Do you think a general example would still add value?

(Some) Configuration via Web UI. This one might be an issue as certain settings shouldn't really be changed this way and it adds more cruft :(.

Currently, all options are configured via CLI and aren’t persisted between restarts. What would Web UI configuration mean in this context? For example, if you changed a setting in the Web UI, would it be acceptable for it to reset upon restart?

For the desktop version, all options are already configurable and persisted, but for the server, the lack of persistence complicates things. Are there specific options you feel would benefit from being configurable live?

The upload/download rate limits, for instance, are already live-configurable via the API, and I agree this is a good use case to expose in UI. Are there other options you had in mind? What options not being temporarily editable / editable through UI caused pain in the past?

[mpmc]

Thanks @mpmc for kind words!

I don't see any downsides in doing the first 2 (baseURI), proxying rqbit's API sounds reasonable. We may keep the issue around just for these, they shouldn't be hard to add.

Below are comments / questions on others

Magnet editing on "add from magnet" dialog for (adding trackers etc), similar to https://madeby.lynx.pink/magnets/.

Could you elaborate on the use case here? For example, do you primarily want to add trackers manually? If so, that's already possible via the API, and exposing it in the UI wouldn't be too hard. However, a full-fledged magnet editing feature would be more complex. What specific features, aside from adding trackers, do you think would be valuable here?

Bingo! Adding a text field to the UI (to add more trackers) would be fantastic.

I've also thought of another (perhaps more user friendly?) addition too, which would also add more usability to the Web UI.

• Allow selecting multiple existing torrents to perform actions, for example, adding additional trackers, pause, delete etc.
• When adding/updating trackers; load additional trackers from a URL (saveable in the config?) or file directly into the text field.

(I noticed how much of a chore deleting 20 or so torrents one by one is >.<).

Add SystemD unit to docs. [I wrote my own (horrid IMO) service file here.

Your file actually looks fine to me! It's clear and functional. That said, it seems very tailored to your specific setup. Adding an example SystemD unit file to the docs might not be universally helpful, as most users with the knowledge to create a unit file would already know that "rqbit server start" is the key command. Do you think a general example would still add value?

A general example yes. I thought mine was horrid mainly for the reason you've pointed out (tailored to my setup) , although it should work as long as rqbit is in $PATH.

(Some) Configuration via Web UI. This one might be an issue as certain settings shouldn't really be changed this way and it adds more cruft :(.

Currently, all options are configured via CLI and aren’t persisted between restarts. What would Web UI configuration mean in this context? For example, if you changed a setting in the Web UI, would it be acceptable for it to reset upon restart?

For the desktop version, all options are already configurable and persisted, but for the server, the lack of persistence complicates things. Are there specific options you feel would benefit from being configurable live?

The upload/download rate limits, for instance, are already live-configurable via the API, and I agree this is a good use case to expose in UI. Are there other options you had in mind? What options not being temporarily editable / editable through UI caused pain in the past?

Bingo again (you're on a roll)!

• Global rate limit exposed in UI. It could be persistent or per session, and limited to RATELIMIT_DOWNLOAD_BPS value? Oh and maybe (like the above) allow changing the rate limits for multiple torrents?

Bug or user error?

When I set RATELIMIT_DOWNLOAD_BPS / RATELIMIT_UPLOAD_BPS environment vars, they appear to be ignored, passing them as arguments however works as expected.

---

PS: Sorry for taking so long in replying, I hadn't updated my e-mail forwarding & wasn't getting github e-mails!