Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

MC stores user-specific settings. This is usually fine, but it does make it difficult to deploy MC in a multi-user environment, if you want all users to access the same Library with the same settings.

I'd like a Share settings across user accounts option, which when enabled:

* Prompts the user that all current settings will be copied to system-level shared settings. Are you sure (Y/N)?
* Sets a flag in HKLM (on Windows, and in a shared location on OSX/Linux) that tells MC, when loading, to use the settings stored in HKLM instead of HKCU.
* All settings for all users are accessed in HKLM (or, again, a shared ini file on OSX/Linux), with otherwise the identical registry keys and locations.
* If MC's User Accounts setup is enabled, block all users from altering this setting except the Administrator.
* If it is turned back off, set the flag back to 0 (the default) and copy the current HKLM settings back to HKCU (perhaps with another "will copy, ok?" prompt)

This would need to be optional and non-default because, once stored in HKLM, users would have to UAC elevate to write any new settings to HKLM (on Windows). That's actually a benefit for me because I want to prevent users from mucking with the settings once they're set. Linux and OSX likely wouldn't have this issue because the INI could be stored in a shared location where all users have R/W access to it (though if you wanted, you could set up the same security by simply editing the mod permissions on that file).

I have this issue with some of my work deployments. In particular, I use MC on our 84" Perceptive Pixel display, which is in a public conference room. Any Active Directory user can log into this computer and use it without any prep work.  And, I use MC in Theater View mode to connect to the VM instance of MC that serves my work-specific Library, so that users can access our library of marketing and lecture videos for things like tours and classes. Unfortunately, it is difficult to get MC set up properly so that it automatically has the right settings when the users log in, because by default they all "start fresh".

Similarly, I can imagine a family with logins for each of the different family members customized for them. I don't do this anymore at home (and we run with a shared login on all of the PCs) and MC is one of the biggest reasons why. I can see in some instances where different users of MC would want their own Library and settings on the same PC. However, probably just as often (or maybe even more often) it would be better for MC to "match" on all users' accounts, because you have a family Library.

Right now, the only way to solve the two issues above is with custom scripting which is difficult to implement reliably. And, if you don't have a Windows Domain and your users run as limited users rather than admin users, it is essentially impossible to solve (because the limited users can't import a REG file without elevating). I can actually solve my work problem, somewhat, with Group Policy on our AD domain (which can import a REG file), but it doesn't always happen reliably immediately at login, and often doesn't take effect until the second login, which makes it tough to use. All of that is, of course, way above the capabilities of the average home user.

So, an option in MC to cover these cases would be good.

[mwillems]

This would be very useful.  We only have single user PCs at home for this exact reason. 

[gvanbrunt]

These things should really be stored in the Library itself and tied to MC user accounts. That way the settings "could" also be used remotely if wanted. I know some are device independent, but those could be relegated to that device.

This is really going to be needed for JRiver's plans to use media anywhere. Any way to adapt your plan so it works using the db instead? I think using the registry and "whatever they use" on other platforms shows it's not the optimal location as it is.

[glynor]

These things should really be stored in the Library itself

No. Many of the settings are not Library specific. They include things like:

* Which Libraries are loaded and which one is currently active.
* All Audio and Video options
* Zones
* Startup Options and user interface options (like Skins)

How are you going to store the settings for which Libraries are loaded within the Library? Similarly, Libraries are portable. They can't include machine-specific things like Audio and Video options. Otherwise, when I use my External Disk Library on my laptop vs server PC, it'll be all messed up on one or the other, and I'll have to re-do all of the settings.

Many of them are, however, Library specific and are already "functionally" (if not actually) stored as part of the Library because they're in the Library Specific sub-keys of HKCU. This includes things like Auto-Import options, Theater View setup, and Media Network setup. Those could be moved into the actual Library database files. I imagine they aren't because the database isn't optimized for that kind of key-value storage.

I think using the registry and "whatever they use" on other platforms shows it's not the optimal location as it is.

On other platforms settings are stored in INI files, the interior of which is just basically a REG dump of the Windows registry settings.  These are stored in the equivalent of AppData for those platforms (eg in ~/Library/Application Support/J River/ on OSX). The argument could certainly be made to dump using the Registry on Windows and to go to INI files for all platforms.  That would unify the code further, though it could actually decrease performance slightly (though likely not in an appreciable manner) since reading and writing to an INI file isn't as well optimized for key-value storage as the Registry.

Of course, they could just have a separate database that is optimized for key-value storage that they make themselves and which is cross platform (or just use some open database format for it, since it wouldn't ever get huge so you don't need to worry about the size of user's Libraries). But that's a whole pile of work for very limited gain.

[glynor]

In any case, I'm not asking for anything so revolutionary.  All I'm asking for is the option and when the option is enabled, it takes the settings loading/saving functionality that is already there, and just points it at HKLM instead.

On OSX (and I assume Linux) it already saves Machine and User settings in separate INI files, here:
~/Library/Application Support/J River/Media Center 20/Settings/Machine Settings.ini
It is just a little silly because the Machine settings INI is stored in the user's home Library folder, so it has to be recreated for all users.  That should be moved to:
/Library/Application Support/J River/Media Center 21/Settings/Machine Settings.ini
And if that file contains the flag enabled, then it uses:
/Library/Application Support/J River/Media Center 21/Settings/User Settings.ini instead of the default location in the home directory.

Same logic could be used for Linux, just substituting the path locations that are used on Linux.

[gvanbrunt]

Gotcha. I agree in the cases you specified. Now that you mention it. I think almost everything else had already been moved to the DB. I think I'm just thinking of how it used to be.

[rudyrednose]

+1, this option would be nice to have.

[locust]

+1, I'd really like to see this as an option

[Hendrik]

Can't write to HKLM without admin access or UAC elevation, not convinced worth the effort to mess with the beast thats UAC. Can't elevate a running process properly, so you would have to start MC knowing that you want to make changes (and we would have to verify every registry access that we dont open it for reading and writing all the time, which we might simply do now). Seems very borderline useful..

[gvanbrunt]

Can't write to HKLM without admin access or UAC elevation, not convinced worth the effort to mess with the beast thats UAC. Can't elevate a running process properly, so you would have to start MC knowing that you want to make changes (and we would have to verify every registry access that we dont open it for reading and writing all the time, which we might simply do now). Seems very borderline useful..

As pointed out by Glynor, you already write to ini files on other os's. Why not do that on win too and never worry about UAC for any writes? You can write them to program data folder an all can access it...

[glynor]

ProgramData might be similarly protected for Limited Users. I'm not sure... But if so, C:\Users\Public\Documents\JRiver\ would not be and would be easy to make globally writable by all users.

I'd originally been thinking that UAC would only be required for when you click OK to the settings dialog, but after Hendrik's post, I realized this isn't the case.  Changing DSP, or adding a Library, for example, would require the same thing.  So, I agree, that would be too unmanageable.

But, unifying the code further and solving this issue in one go seems like it could be a good target.

[glynor]

I looked it up.  You can do it in ProgramData, if you set permissions on the folder at install time.

[john_kane]

This would jell nice nicely with the aforementioned feature request to run MC2x server as a windows service. Solves some of the other parts of the multiple user problem.

[glynor]

This would jell nice nicely with the aforementioned feature request to run MC2x server as a windows service. Solves some of the other parts of the multiple user problem.

Running MC as a service is a difficult challenge and would require a substantial code re-write. That re-write wouldn't provide a massive gain in features (and a loss of some features, honestly). It has been discussed a whole bunch of times, going back a decade. I don't think it is likely.

Still, though, if this were implemented, it would make hacking it together yourself much easier.