Adding a few startup options to the daemon.

[blacke4dawn]

I would like that the options for total upload/download limit, global share ratio and DHT/PEX be added to the daemon itself as well. I don't really see a reason why those should be only settable by other tools/clients.

Currently I have modified my distros init-script to set those via transmission-remote but it is a clumsy method.

[tarr]

The daemon always uses settings.json, why not just change it there? You don't need to have all options on the command line. It is a good idea though to relocate the default config directory using -g to a place like /var/lib/transmission, having it at ${TRANSMISSION_USER_HOME}/.config/transmission-daemon is a pain.

[blacke4dawn]

I have already relocated the configs and such to a more "central" directory.

However consider this, if the settings are read from settings.json then why does the daemon have so many options for startup. Why not relocate everything that can be relocated to transmission-remote only?

If it is a "left over" from the time before setting.json was used then why wasn't those settings in for the daemon from the start?

[Jordan]

However consider this, if the settings are read from settings.json then why does the daemon have so many options for startup. Why not relocate everything that can be relocated to transmission-remote only?

If you look at the transmission-daemon command line options, most of them are related to how clients are allowed to connect to it. There are a few arguments that probably should be moved to transmission-remote, but you know how it is -- once you add a feature, lots of people get unhappy if you remove it...

Anyway, this isn't a mistake that I want to compound by adding more arguments to transmission-remote. Editing settings.json is the "correct" way of setting these preferences.

[blacke4dawn]

However consider this, if the settings are read from settings.json then why does the daemon have so many options for startup. Why not relocate everything that can be relocated to transmission-remote only?

If you look at the transmission-daemon command line options, most of them are related to how clients are allowed to connect to it. There are a few arguments that probably should be moved to transmission-remote, but you know how it is -- once you add a feature, lots of people get unhappy if you remove it...

Anyway, this isn't a mistake that I want to compound by adding more arguments to transmission-remote. Editing settings.json is the "correct" way of setting these preferences.

I get your point here but my main point there was that if the correct way to change those is to "edit" settings.json then why even have them for the daemon-binary itself (especially considering the added remote options with 1.80). If this is a leftover legacy from a time before setting.json was used (no idea about that) then why wasn't up/down-load limits in back then?

Personally I see at least up/down-load limits equally important to not "choking" your line as peer limits, or even a little higher since they have no default limits (beyond what your hardware can deliver).


Maybe it's just me but I prefer to have cmd-options or config file for daemons, not both. Especially when a few of them are only settable via one method.

[Jordan]

I feel like you just ignored what I said and restated your earlier point.

Yes there is some overlap between the daemon's command line arguments and settings.json. Settings.json is the preferred way of changing configuration options for the daemon. Just because I haven't removed those command-line arguments, is not a reason to add even more of them.

Also I don't know what you mean about emphasizing `daemon' vs some other app