Opened 9 years ago

Last modified 6 years ago

#5115 new Bug

Shared Settings

Reported by: user967 Owned by: mike.dld
Priority: Normal Milestone: None Set
Component: Qt Client Version: 2.73
Severity: Normal Keywords:


I run a remote transmission-daemon, and connect to it using transmission-qt.

Sometimes I also run a local transmission-gtk session also, and it has often picked up incorrect settings for the daemon, such as filesystem paths that do not exist on the local system.

This is annoying, I end up needing to adjust some settings on the occasion I use gtk client. It could potentially lead to some unexpected behavior.

Change History (11)

comment:1 Changed 9 years ago by livings124

This should be covered by #2768

comment:2 follow-up: Changed 9 years ago by livings124

  • Resolution set to duplicate
  • Status changed from new to closed

comment:3 in reply to: ↑ 2 Changed 9 years ago by user967

This is not a feature request, rather it is unexpected behavior that has to do with how settings are stored in ~/.config/transmission.

If the directory does not exist, a new settings.json is created when using transmission-qt to attach to a remote daemon. It contains the settings of the remote server, such its port, download-dir, etc.

If transmission-gtk is started, at the same time or later, it will use the configuration of the remote daemon.

It would be nice to be able to use transmission-qt as a remote and transmission-gtk as a standalone client on the same system, without the settings overlapping in this way.

comment:4 Changed 9 years ago by user967

  • Resolution duplicate deleted
  • Status changed from closed to reopened

I think this is a distinct matter from the other ticket, though that would also be nice.

comment:5 Changed 9 years ago by rb07

The ticket is missing a point: all the programs you mention have the ability to use different configurations, its a parameter (-g or --config-dir) and you can use it to run as many different instances as you want.

If you don't use the parameter, and expect a program to detect that something else is running, or has been running... IMO this ticket is invalid (and not the first one about the same matter).

comment:6 follow-up: Changed 9 years ago by user967

I am aware, in general, how to run sessions with distinct settings.

What is not clear to me, is why the remote settings are copied at all, as they are meaningful for the daemon, and are simply displayed by the remote.

If remote truly needs to store the daemon settings, perhaps they should be moved to a special section of settings.json.

I believe it is most typical to run transmission-daemon as a system-wide instance and/or remotely. If so, the most common usage of transmission-qt seems to conflict with any default single user transmission instance, either simultaneous, or at another time.

comment:7 in reply to: ↑ 6 Changed 9 years ago by rb07

Replying to user967:

What is not clear to me, is why the remote settings are copied at all, as they are meaningful for the daemon, and are simply displayed by the remote.

Why not? The library was designed to work with all applications, so it stores settings locally (no matter what application is using it). The GUI adds some settings that are only used there (window size and placement, for instance).

I believe it is most typical to run transmission-daemon as a system-wide instance and/or remotely.

Again you are missing an important point, transmission-daemon as a service should be configured to run as its own user, not a regular, desktop using user. For security reasons many Linux distributions create such special users to run daemons, or use user "nobody". Also keep settings on a global repository, /etc usually contains the configuration of most, it not all, the daemons.

So, where is the bug? Just because the user doesn't want to configure his system, or his different instances of related applications, is this a bug? No in my opinion (I'm not a Transmission developer), you are given the necessary tools.

comment:8 Changed 9 years ago by user967

This is not a matter of what is possible to configure correctly, but rather a matter of default config paths causing problems in more common cases, for no apparent benefit.

Here is a simple, local-only example, on Ubuntu 12.10 with Transmission 2.72:

  • Install transmission-daemon. This by default starts a system-wide daemon on boot. It is configured with a default settings.json including download-dir "/var/lib/transmission-daemon/downloads", owned by special user "transmission-daemon".
  • Connect to the daemon with the only official remote gui client, transmission-qt on default port, requiring preconfigured username/password "transmission".
  • When transmission-qt is quit, a ~/.config/transmission/settings.json is created with the settings of the daemon, including its download-dir, peer-port, rpc-port, remote-session-username, remote-session-password, etc. These settings are not readable by a normal user, but can be copied in this way if you have the daemon login.
  • Try transmission-gtk instead... and a variety of unexpected behavior can result, regardless of whether transmission-daemon is even still running or installed. For example, download-dir is set to a directory owned by "transmission-daemon", so downloading anything will result in an error. It is not hard to imagine various other problems.

While perhaps nobody has complained of this specifically, and for me this is just a minor annoyance, it seems to me that it could be avoided entirely just by having transmission-gtk and/or transmission-qt not use ~/.config/transmission. I notice that starting a user session of transmission-daemon creates ~/.config/transmission-daemon instead, so I am not understanding why the other two apps should share settings by default. I am having trouble thinking of any typical use cases where that would be desirable.

As I said before though, it is not really clear to me why transmission-qt writes the daemon's settings to ~/.config/transmission/settings.json at all. If that is not necessary, I think any problem is also avoided by not saving them, just reading when connected, as it must do anyway.

comment:9 Changed 9 years ago by user967

Furthermore, transmission-qt will overwrite the settings for transmission-gtk every time it is connected to a daemon.

transmission-gtk seems to be the default bittorrent client for many linux distros, and it appears to me, that basically any use of transmission-qt will cause this default client to become misconfigured.

comment:10 Changed 9 years ago by user967

I moved my UI to a different machine, and have run into this once more.

I am surprised it does not seem to be considered a problem. It is simply a matter of sensible default config locations for the various clients. They should not reconfigure each other when used in distinct and intermittent fashion.

comment:11 Changed 6 years ago by mike.dld

  • Owner changed from jordan to mike.dld
  • Status changed from reopened to new
Note: See TracTickets for help on using tickets.