Bug 6791 - Store --prefsdir path in preferences
: Store --prefsdir path in preferences
Status: RESOLVED INVALID
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 7.0
: PC Windows XP
: P2 enhancement (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-25 23:48 UTC by sbjaerum
Modified: 2008-01-26 15:07 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sbjaerum 2008-01-25 23:48:27 UTC
When starting SC using slimserver.pl --prefsdir <path>, I think it would be nice if the specified path was stored to the preference system. Subsequently, SC should use this stored prefsdir location without explicitly having to specify it on the command line.

Same applies to --cachedir and --logdir.
Comment 1 KDF 2008-01-26 01:06:21 UTC
prefsdir in the prefs file would be a bit circular.  what if user uses --prefsdir to point to a prefs location, and the prefs file there points to another dir? cachedir is already in prefs, logconf is a command line option to point to config file which can set the location.
Comment 2 sbjaerum 2008-01-26 01:21:29 UTC
If --prefsdir is present on command line, my thought is that it should override and replace whatever is in the preference file in that directory. That way it won't be circular.
Comment 3 Michael Herger 2008-01-26 03:23:08 UTC
The prefs file path isn't stored anywhere. Either you define it on the command line or a default value is used. We could use the registry on Windows systems. But it's imho not worth the effort, as users who're switching versions, should be able to define the prefsdir path.
Comment 4 Mark Miksis 2008-01-26 14:16:17 UTC
I'm confused about how this would work.  If I start SC with "--prefsdir /some/non/standard/place" and then later restart it it without "--prefsdir", how is SC supposed to find that previously used prefsdir?
Comment 5 sbjaerum 2008-01-26 15:07:19 UTC
Not a good idea after all. I'm invalidating the bug.