Print

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

[Matt]

We're considering adding support for user accounts.

The idea is that you could expose different library content to different accounts, and password protect any accounts you wanted.

There are two main approaches to doing this:

1) Discrete library for each account

This has clean boundaries, but messy maintenance.  For example, moving shared content requires updating each library individually.


2) One master library with accounts

Conceptually, this approach would be like an expanded Access Control system.  This simplifies configuration, but makes it so accounts all share playlists, library views, etc.  This means a playlist or view created by one user would automatically appear (with content filtered) to another user.


Anyone have any advice?  Thanks.

[Lasse_Lus]

i would say, MC is very much about  maintenance, so i would definitely choose NR 1, i already have a "messy" library, sharing 200+ views to a newbie means they will get even more confused..

..but maybe that leads to to much work 

anyway, i seek user accounts with different roles, with restricion possibility like "read only"..so clients can't change the (my) library

[Alex B]

I think #1 would be better. Since the auto-import folder configuration is stored in each library individually the auto-importer can handle the external file changes*. You would just need to add a password system.

MC could have a few startup options:

1. Always load a specified default library
2. Load the last used library
3. Present a list of libraries
- In each case MC would ask the password if it is set for the particular library.
- When the user doesn't have the password for 1. or 2. it would be possible to pick another library from the list.
- A master password or some other system to administer the accounts would be needed.

The libary backups can contain also the user options. It might be good to add this feature to the library loader as an option. For example, if the parents prefer to use the home theater system and the kids the desktop speakers the settings would be automatically correct.

Questions:
Would also the library backup files be password protected? Should the restore system require a master password?

EDIT
* For playlists you could add an "auto-save to a playlist file" playlist group. The playlists in that group would be automatically saved to the specified location and other libraries could pick them from there. Perhaps you could extend that to smartlists by creating a file format that can store the rule.

[sunfire7]

In a perfect world I would like the option #1, because it gives you more options to customize the user accounts, but in the real world I would be happy to have the #2, I could have a perfect Master Library (tagged and organized) and then just filter content to users (wich only want to play music, they dont care about playlist or views, etc). So my vote would be option #2.

[HiFiTubes]

I like the delineation of #1, but I love the idea of interactivity and collaboration in #2.

I'm thinking of terms of interactivity, where each client can have a chosen library or specific content loaded, but also allowing people to make playlists, comments, add to metadata, (on files or libraries allowed to) but have that run through a "Verify Changes" done by the admin on the master.

Hope that makes sense. I'm seeing more and more uses for MC in interactive installations like museums etc. and this would really be a special addition to MC.

Forcing all clients to see other views schemes and playlists needs to be verified by an admin; so sync changes back master from any password protected library would need authorization.

Ideally, I'd like to be able to push or load unqiue libraries (library filters) on a client, but also give people the ability to contribute to this unique library, save at an admin level, and keep that library unique but sync back metadata (comment additions) or playlists to a master.

[jmone]

I'd be happy with a setup where you just tag your content for what accounts have what level of access.

[rpalmer68]

I see #2 as a natural extension of the current Library Server.

All clients access a shared library but there is control over what those clients can do and hopefull also see.

Of course LS would need to be able to do a little more than it can now (RIP, add cover art, build stacks, add/edit views etc) but I see this being a more powerful solution than lots of seperate libraies that need maintaining like #1 offers.

[zxsix]

Option 1 wouldn't allow a truly "read only" situation, since that user would need to be able to import new tracks.

Currently I support 4 users in one single database.  Only I do any tagging of audio tracks.  I set up a viewscheme for each person that defines the stuff that that person likes to listen to.  The startup option of "last location" works nicely to keep everyone in their area with no fuss.
I use the /libraryreadonly command line switch for the ones who I want to prevent from changing tags accidentally or otherwise.

I also envision giving close friends read only access via library server.  This would serve the purpose of letting them sample some bands they hadn't discovered yet, and vice versa.   I wouldn't want these people having to do any library management at all.  Only look and listen.

So my suggestion is a single database that support multiple logins.  Each login would have a status of "no access", "read only", or "write access".  You could then go another level deeper for users that have write access and give additional privileges such as "can import new", "can change tags", "can change ratings", "can delete", "can move file locations", etc.

Using this method serves both scenarios, actually.  Those that want multiple libraries (option 1) would still be able to do that, just like they can now.

[glynor]

I would only use this feature if it were implemented with option #2.  Preferably we would eventually have the option to turn parts of the tree on and off on a per-user basis (along with other access permissions eventually).  This would solve the problems targeted by option #1 without forcing you to maintain separate libraries (which is messy and unworkable IMHO).

IN FACT, perhaps this could really eventually solve the problem of separate view setups for Theater View and the Web UIs.  If there was a Theater View user, a WebRemote user, an admin user, and a "default" user, this could be a simple solution to that config ui problem.

[zxsix]

Start with basic yes/no access rights similar to my earlier examples and add "can see audio tree", "can see images tree", etc as described above.  Then open up to user request to list areas they would like protected.  Add a couple new ones per build.

[JustinChase]

Why not combine them?  A main server that manages, is aware of changes to, and serves all media; coupled with user accounts and settings that connect to the server.

I started writing this up last night as I was going to start another thread to throw it out there, but haven't quite finished editing.  however, since you brought it up, I'll just post it here and answer questions if anyone has any.

Media Server – NOT a Library server (“Libraries” are managed elsewhere)

•   Runs in the background on designated machine (faster on machine with media stored?)
•   Serves all media to all users/profiles
•   Has no organizational or visual responsibilities (other than naming and location convention)
•   Cannot be "viewed" or "browsed" directly, only thru an admin user account/profile (see below)
•   Is aware of all media in all locations
•   Automatically imports and watches for changes in all locations
•   Handles codec management for playback, ripping, recording ,etc
•   Ripping and encoding settings should be system-wide, so should be set here
•   Handles file conversion required to deliver media to users/profiles (different users/different needs)
•   Is aware of all devices and connections, and their drive/media sharing allowances
•   Manages any cache files (same copy is shared to anyone requesting a less then full-size version?)
•   Ideally would manage access rights for users/profiles (admin, user, party)

Profile or User – This is a users individual, customizable interface to the system’s Media Server - these things can optionally be shared with other users/profiles

•   View Schemes
•   Playlists & Smartlists
•   Ratings
•   Tags and their settings (defaults to Media Server settings, but can be adjusted)
•   Playback settings (gapless, level adjusted, etc, default to Media Server settings, but changable)
•   Playback stats
•   Visualization settings
•   Handheld settings should probably go here, as they typically “belong” to a user, so are an extension of them and their playlists and preferences
•   Custom library fields should be setup here
•   Podcasts are setup and managed here, but are stored on the Media Server and available to other users
•   TV can be viewed live*** or recorded, programs can be set up to record and deleted from here (deletions might need other users to “allow” deletions, to avoid fights)
***   This is true no matter where the actual tuner is installed, as long as that device is connected to the Media Server

Devices – This is any device that physically (or wirelessly) connects to the Media Server (including playback only zones)

•   Other computers
•   Handheld devices
•   DLNA devices
•   Web connections
•   These may or may not have Media Center installed on them.
•   If MC is not installed, the settings are automatically set/determined by the Media Server
•   If MC is installed, settings can be adjusted from what the server defaults are
•   Resolution, network connection speed, sound and video card capabilities, output connections are set per device
•   Devices settings will be used for any user/profile connecting on them
•   Most/all will allow playback on them

Putting it all together

•   Pretty much all the settings are stored by the Media Server, and are given/loaded to the device based on the Profile that connects
•   The Media Server and the Profiles are separate entities – the Media Server is the heart of the system and manages everything
•   The Media Server does most of the processing and just sends the smallest possible file (if conversion is requested or necessary) to the device, based on user/profile settings, and/or limited capabilities of the connection (wireless for example) or of the device (small screen size on mobile device does not need 8mb image files sent to it, for example)

Maybe this helps...

Think of the Media Server as the books and magazines and videos in your local library, all sitting on their shelves.
Think of the users/profiles as the card catalog, they know and document and help you find the books and magazines and videos on the shelves
Think of the devices as the thing you use to manipulate the card catalog to help you find the books and magazines and videos on the shelves (the actual card files, or computer, or tags on the shelves)

The Librarian is the connection between the card catalog and the books and magazines.  it knows how to take your need/request and fetch the best possible version of the book, magazine, etc, as relayed by the card catalog.

MC should hide the Librarian, and just know the best way to get what you request, based on all the information stored in the Media Server about available media, connections, and playback preferences and abilities, and just makes the right connections internally to present the best version to the user/profile.

I think this solves most/all of the client server requests and debates I've seen over the years.  Other than the (possible) difficulty of implementation, I don't see any downsides to this approach.

I started a thread on it a while back, it has more details, but Jim said it was confusing i hope this helps

http://yabb.jriver.com/interact/index.php?topic=57440.0

[HiFiTubes]

I like what I read in your other thread re client machine having an option where you could choose to filter out Video for example.

But I'm confused why the master is hidden? I have clients and I tag from some and sync back, but the master is where I sit down and work the most and the files are stored their physically.

So i want to be able to sit down at the master and be able to create custom libraries/accounts out of all my schemes, expressions, and other goodies and offer them as password protected libraries/accounts from any client. But also to be able to monitor any changes or additions done on the client.

I creat an account for my son and filter certain stuff and he makes playlist all weekend or he rips 2 CDs and tags them; then i could execute a "review account changes" option which let's me survey changes that clients are requesting to sync back to the master. Obviously sync changes can already be disabled too. Maybe the master would have to delinate certain client accounts for some features e.g. Client 1 playlists, client 2 playlists, etc. Whereas tag changes could be not just approved but MERGED (think of wiki where client adds to comments).   

[HiFiTubes]

I think #2 is a not a forward thinking approach with forcing sharing of schemes and playlists. That's assuming one user "in house".

The simplest step forward is to just add a filter, based on IP?, so the master can save a template for that IP when it requests the library. 

 

[flac.rules]

I would like #1 in combinations with being able too choose a library on the library server from the client. Lets say you have 10 libraries on the library server, with different content (and/or different views), user account a lets you access library 1-3, account b 4-8, account c 8-10 and account d 1-10 (or a similar setup) on the client. That would make access control pretty easy, and you can also use it to have a neat non-cluttered list of libraries.

[bunglemebaby]

I would only use this feature if it were implemented with option #2.  Preferably we would eventually have the option to turn parts of the tree on and off on a per-user basis (along with other access permissions eventually).  This would solve the problems targeted by option #1 without forcing you to maintain separate libraries (which is messy and unworkable IMHO).

Glynor summed up my main thoughts pretty well, so +1 to this.

My gut says that #1 wouldn't wind up being used by all but a select few once they realized how much maintenance was required to keep all users synced up. There would be some advantages (could be disadvantages too depending on usage), such as individual ratings and playcounts for each user account, but without some sort of automated way to perpetuate other metadata it just doesn't seem like a realistic solution IMO.

Ideally to me, a user account should be equally useful for both a user and a device. So I could have a user account for both my wife and myself, then a user account for our living room and bedroom TVs. I imagine if you expand this to somebody with a more glamorous setup it's even more appealing. This does also beg the question of: how this would work with 3rd party DLNA clients?

-JB

[flac.rules]

Glynor summed up my main thoughts pretty well, so +1 to this.

My gut says that #1 wouldn't wind up being used by all but a select few once they realized how much maintenance was required to keep all users synced up. There would be some advantages (could be disadvantages too depending on usage), such as individual ratings and playcounts for each user account, but without some sort of automated way to perpetuate other metadata it just doesn't seem like a realistic solution IMO.

Ideally to me, a user account should be equally useful for both a user and a device. So I could have a user account for both my wife and myself, then a user account for our living room and bedroom TVs. I imagine if you expand this to somebody with a more glamorous setup it's even more appealing. This does also beg the question of: how this would work with 3rd party DLNA clients?

-JB

I guess i agree, or I would like a kind of hybrid solution, that is, many libraries, but any user can have read or write access to any library.

[Alex B]

I am merely thinking about giving each user a personalized user experience. The #1 would not require that an administrator would need to maintain each account after it has been created.

The users would be able to learn to use MC and customize their own user environment without affecting the other users' environments.

In addition to customizing the personal views and settings each user would be able to fully maintain (add, change, delete) personal files in a designed storage location, and if allowed, also public files in another designed location. A user would not be able to access the other users' personal files from inside MC. To make these things possible the auto-import configuration could be locked and have some additional functionality that could limit the access rights for each included location. Also the drives and devices tree branch and the other ways the access files & folders outside the library could be disabled or restricted.

The password system would only be a nice add that would force the users to select their own account or an unprotected account. Any protection system inside MC would probably not be able to prevent unauthorized access to certain files or areas inside the computer. To get full protection it is better to use the Windows user accounts.

Probably all this could be included in the #2, but I am afraid that it would be a hugely complex system and creating it would require a lot more work from the developers.


EDIT

Matt didn't say anything about network/servers/clients so I assume that at this stage the intention is to create a system for user specific local libraries or user accounts in a single library.

[flac.rules]

Well, remote or not, I would like the settings to be done per library, and have users given access to a given set of libraries. Like #1 i guess, except that the library is not restricted to just one user (unless you want) and the user is not restricted to just one library.

[JustinChase]

I assume this is directed at me...

But I'm confused why the master is hidden? I have clients and I tag from some and sync back, but the master is where I sit down and work the most and the files are stored their physically.

So i want to be able to sit down at the master and be able to create custom libraries/accounts out of all my schemes, expressions, and other goodies and offer them as password protected libraries/accounts from any client. But also to be able to monitor any changes or additions done on the client.

I creat an account for my son and filter certain stuff and he makes playlist all weekend or he rips 2 CDs and tags them; then i could execute a "review account changes" option which let's me survey changes that clients are requesting to sync back to the master. Obviously sync changes can already be disabled too. Maybe the master would have to delinate certain client accounts for some features e.g. Client 1 playlists, client 2 playlists, etc. Whereas tag changes could be not just approved but MERGED (think of wiki where client adds to comments).

I'm not sure what you mean by "master is hidden", but I think you are interpreting that the master library is being hidden.

With this system, there are no libraries.  libraries currently contain both the server portion and the user/profile portion.

My solution/suggestion is to split them up.  the Media Server is only required/able to serve media, so there is no "direct access" to it as you're used to.  it just sits on the machine waiting for a user/profile to connect to it.  So it's not "hidden", it's just not something that can be seen/used/manipulated without connecting with a user/profile.  by default Media Center would install the Media Server AND a user/profile, with full admin rights.

this user/profile connection is what you use to manipulate the files and tags and most of the things you're used to managing with the current library system, but not everything.

Glynor summed up my main thoughts pretty well, so +1 to this.

My gut says that #1 wouldn't wind up being used by all but a select few once they realized how much maintenance was required to keep all users synced up. There would be some advantages (could be disadvantages too depending on usage), such as individual ratings and playcounts for each user account, but without some sort of automated way to perpetuate other metadata it just doesn't seem like a realistic solution IMO.

Ideally to me, a user account should be equally useful for both a user and a device. So I could have a user account for both my wife and myself, then a user account for our living room and bedroom TVs. I imagine if you expand this to somebody with a more glamorous setup it's even more appealing. This does also beg the question of: how this would work with 3rd party DLNA clients?

-JB

This is solved by my solution above.  You don't need user accounts for you and your wife and your TV's, you just need user accounts for you and your wife (and kids and guests if you wish).  when you use a device (your TV's), the Media Server prompts you for which user account you want to use (including a password if you wish) and then displays the media and ratings and views, etc associated with your user account *ON* your TV (or laptop or whatever).

So, if you connect with your account, you get Slayer songs as 4 and 5 stars, but your wife sees them as 1 and 2 stars on her account (for example); anywhere she connects, independent of the device used to connect.  the device is only a playback and connection medium, not something to be "customized" as a traditional library or user account.  it's just the computer or TV or whatever.

TV's are a bad example, since they can't have MC installed on them, but the function is basically the same as a laptop that has MC installed, except they can't change anything like a device with a copy installed could.  They are just playback devices, showing user/profile accounts.

I am merely thinking about giving each user a personalized user experience. The #1 would not require that an administrator would need to maintain each account after it has been created.

The users would be able to learn to use MC and customize their own user environment without affecting the other users' environments.

In addition to customizing the personal views and settings each user would be able to fully maintain (add, change, delete) personal files in a designed storage location, and if allowed, also public files in another designed location. A user would not be able to access the other users' personal files from inside MC. To make these things possible the auto-import configuration could be locked and have some additional functionality that could limit the access rights for each included location. Also the drives and devices tree branch and the other ways the access files & folders outside the library could be disabled or restricted.

The password system would only be a nice add that would force the users to select their own account or an unprotected account. Any protection system inside MC would probably not be able to prevent unauthorized access to certain files or areas inside the computer. To get full protection it is better to use the Windows user accounts.

Probably all this could be included in the #2, but I am afraid that it would be a hugely complex system and creating it would require a lot more work from the developers.


EDIT

Matt didn't say anything about network/servers/clients so I assume that at this stage the intention is to create a system for user specific local libraries or user accounts in a single library.

the system described above does give users a personalized experience, and allows them to customize as they learn.

The Media Server would be used to do exactly as you describe, limit user access to files and/or locations, based on what the admin designates, or what a user allows.  for example, I might restrict access to images on the Media Server to only my account, and no one can see/use/change/manipulate those images from any other account from inside Media Center.  I agree this is not network security, and windows settings go much further, but as far as allowing access from inside Media Center, this would work well.

I disagree that this needs to be hugely complex to implement.  We already have most of this in place, we just have the parts mixed up.

Take all the settings and controls and tie them to the Server, put all the individualizations into user accounts and MC can manage the connections as it currently does, but better and more seamlessly.

this is not to say it would be easy, but I don't think it would be as hard as it might seem, and Matt sounds like they are willing to put forth some effort, so I'd rather see them go the extra mile and get the "perfect" system, instead of adding bits and pieces to the library system and not get the full functionality and usefulness that has been requested for years.

So far, I haven't seen anyone say that either of the 2 choices Matt has suggested are the ideal solution, but seem to want parts of both.

The system I've described provides a solution for everything I've seen suggested by anyone as far as individualized user access or client/server functionality goes.

[Matt]

First, thanks for all the feedback.

To frame the discussion a little, let me say that Media Network (servers & clients) are an important part of this.  It should be possible for different clients to see different things.

Also, any changes will be incremental.  For example, we might start by adding passwords to libraries (#1) or expanding Access Control (#2).


My personal inclination is that there should be a single library with more powerful access management.  I can't think how else to deal with a home network with several clients and a single machine that records television.  The television recording machine must somehow have a master list of everything any client wants.  It can filter what it shows to any given client, but how could it work if it didn't have all the recording rules because they were scattered across multiple libraries?  You might be able to load multiple libraries at once, but this is effectively the same thing as one big library with different views.

[glynor]

My personal inclination is that there should be a single library with more powerful access management.  I can't think how else to deal with a home network with several clients and a single machine that records television.  The television recording machine must somehow have a master list of everything any client wants.  It can filter what it shows to any given client, but how could it work if it didn't have all the recording rules because they were scattered across multiple libraries?  You might be able to load multiple libraries at once, but this is effectively the same thing as one big library with different views.

I'm right there with you, Matt.  Having multiple libraries can be useful for completely different data sets that you'd never use simultaneously.  However, maintaining separate libraries is really a challenge if they actually reference similar (or identical) media files, and seems like a lot of work for limited gain.

I've been pulling for a "true" network server enabled version of MC for a long time.  If this is one step down that road, I'm all for it.

In the end, I think what we need is a solution where one machine can run and serve a "unified" library, which can be accessed by different users (by "users", I  mean BOTH different people with different permissions AND devices with separate "view" needs).  All changes done by remote copies of MC need to be able to be saved back "transparently" to this master database.  The current Library Server system is close, but is still effectively read-only for network machines (I know you can now manually sync changes back, but this is still clunky and prone to failure).  Plus, some of the functionality seems duplicated via the DLNA stuff, Theater View, and the WebRemote/WebPlay stuff.

This would be an opportunity to unify all of that with a single UI paradigm.  Obviously it isn't going to happen all at once, and I'm patient.  But I really think separating the functionality into separate and distinct libraries is going to hamstring the capabilities of the system in the long-term.  It might get a few people to where they want to be quicker right now, but for the long view, I really think it would be quite limiting.

[Alex B]

So it would be important to separate the media selection and personalized user environments (as JustinChase said).

Assuming a single PC/MC instance has several users or user groups with different tastes, exceptions and skills (e.g. parents, kids, grandparents, guests, etc) there is

1) a need for switching between different personalized view configurations, playlists, playback settings, etc

2) and separately a need for switching between different selections of media (family stuff, kids stuff, rated stuff, highly personal stuff, etc).

When each user uses a personal computer (or an individual OS level user account on any computer) only the latter is important, but I guess the situation is often mixed. Some computers are more or less personal and some not (like a HTPC in a living room).

[JustinChase]

My personal inclination is that there should be a single library with more powerful access management. 

Matt, when you say "a single library", it sounds like you mean to basically keep the current system which says that song X is rated 5 stars; and every user that accesses that library sees that song X is 5 stars. 

I hope this can be changed.  My wife and I have VERY different musical tastes.  having the user/profile setup described above lets us each have our own ratings and such, but the same file just sits on the server unaffected by either of our settings/ratings.

does that make sense?

If you mean "a collection of media files", we are on the same page.

I can't think how else to deal with a home network with several clients and a single machine that records television.  The television recording machine must somehow have a master list of everything any client wants.  It can filter what it shows to any given client, but how could it work if it didn't have all the recording rules because they were scattered across multiple libraries?  You might be able to load multiple libraries at once, but this is effectively the same thing as one big library with different views.

That's exactly what the system above does, but for everything, not just TV.

any user/profile can setup recordings (or rip CD's or DVD's or import images, or whatever) and the Media Server portion processes these requests (since the user/profile is just a connection to the Media Server), and the created files are automatically available to any user/profile that connects to the Media Server (limited by access restrictions if requested), because they all connect to the same Media Server and *it* knows what's available at all times.

So, user Tom connects to the Media Server & requests that Friends be recorded every day at 7pm.  The actual recording is done by the machine with the tuners installed, stores them in the location set by the Media Server, and the recorded shows are now available user Tom *and* to all users; automatically.  All users know this new content is available, because they MUST connect to the Media Server and *it* knows what's been recorded (or ripped or imported).

No one needs to try to keep libraries in sync, or settings or paths or anything else.  the Media Server manages this, and users just connect and see what's available.

It might be nice if the Media Server presented a list of newly created/imported content to a user when they connect, but probably isn't necessary.

perhaps a default smartlist for "newly created media" that pulls based on a tag the Media Server creates, or time of last connection??

[JustinChase]

So it would be important to separate the media selection and personalized user environments (as JustinChase said).

Assuming a single PC/MC instance has several users or user groups with different tastes, exceptions and skills (e.g. parents, kids, grandparents, guests, etc) there is

1) a need for switching between different personalized view configurations, playlists, playback settings, etc

2) and separately a need for switching between different selections of media (family stuff, kids stuff, rated stuff, highly personal stuff, etc).

When each user uses a personal computer (or an individual OS level user account on any computer) only the latter is important, but I guess the situation is often mixed. Some computers are more or less personal and some not (like a HTPC in a living room).

My thinking is that when anyone launches Media Center, it asks who they are, or presents a list of users/profiles to choose from.

You click on the one you want to use, and get the customized experience associated with that account.

This is device independent, anytime Media Center launches or connects to the Media Server, from any device, it forces you to select the user/profile.

I don't understand #2; or more specifically, how it's different from #1.  The kids user/profile can be setup to only allow/include the items deemed appropriate by whoever sets up the profile, the admin or parents' account most likely.  This profile mediates what is shown/available when connected using this profile, including selections of media and views and ratings; everything that might change from one user to another.

However, I might be missing the point/difference, sorry if I am

[Alex B]

For instance, I may want to use my personalized settings with my latest configuration tweaks and access a different media selection (e.g. "family" when I am going to play or show media files to others) even though I also have a media selection that is for me only.

[MusicHawk]

My wife and I have VERY different musical tastes.  having the user/profile setup described above lets us each have our own ratings and such, but the same file just sits on the server unaffected by either of our settings/ratings.

How do you handle this now? Found a clever way?

I do it via Keywords -- lots of them -- to identify and classify music. This is detailed enough that I can then select what I like, and so can my wife, for for playing  and syncing.

Or, Keywords could be used to NAME the people who like a particular track -- or a custom field could be used.

Another method would be to ignore the stock Rating field and use custom fields for rating, one per person, OR a single field with compound values that identify the person+rating.

(I don't use built-in Rating at all, because the UI makes it too easy to mis-click. So I already use a similar custom field, works fine. Of course this means the Stars display is meaningless, but that is the dangerous part of the UI anyway, too easy to click and thereby trash the track. I think it should be possible (or default) to make Stars read-only, so Rating is specified via a normal field.)

[newsposter]

rather than user accounts why not base 'permissions' on playlists?

[JustinChase]

Alex B -  I think I understand now.  Ideally, this system would allow you to push customizations (view schemes, playlists, etc) to other users/profiles, and they would just need to approve the update/change.

so, you could have a family friendly user/profile to show to others, and push your updates from your user/profile to that one; so you'd have the updates, but still have the limits you set for the family account.

MusicHawk - I don't have any clever way to handle this now, so (sadly for the wife) I just maintain the one library, and she just changes the songs she likes to 4 or 5 stars, and we both have to deal with the others favorites.  Not a good solution, but I just don't have the time to try to manage/maintain 2 libraries, and there's ZERO chance she will manage her library, so neither of us really gets what we want

newsposter - user accounts give MUCH more control over the entire experience, vs just playlists

[MusicHawk]

Echoing some thoughts, I've worked with something similar (IBM Lotus Notes) for many years. It's highly-configurable, but some architectures are clumsy or fragile.

What works best is a single server with all content -- media files plus the database (library) app (MC) that catalogs, manages, and provides user access.

(Perhaps beyond what MC needs, Lotus Notes is made more scalable and robust by supporting multiple servers that automatically sync (replicate) with each other so different users can be on different servers, and/or fail-over, and (usually) have exactly the same data on each server. So for the user it generally behaves like a single server. Lotus Notes also can replicate with clients so they can automatically have local current copies of the entire database or a suitable subset.)

Database views can be at two levels. Show a subset for user convenience (but not controlling access), or show a subset to limit user access (enforced by an access control list). The question is, how much "security" is necessary? Is the goal to prevent access to some files -- securing them from any attempt -- or just make it unlikely that the user will go beyond a normal subset? In other words, does a password lock a client or view or entire database/library only in MC, or does it somehow lock up the actual data (media files), even if accessed some other way?

In Lotus Notes and many other databases, the non-secure method is to match users to views. If the user's name has been selected for the view (stored in the view's header so it's portable), the user can access the view. Groups are supported, so view access can be assigned to a group (or several) and users put in groups.

In Lotus Notes, what the user/group can do to data is also specified: read/change/add/delete/copy/print. This can be specified per database, per view, per record, or even at the field level, useful to let users update some but not all fields of a record. (File-level security is provided via encryption.)

More ideas: Lotus Notes recognizes different types of clients, so access/use control can be separately specified for other Lotus Notes clients, Web anonymous clients, Web authenticated clients, Mobile clients, and via access-control expressions, almost any other situation. This combines with the user/group level of control, the tightest control having priority.

To provide user-level preferences in a shared database/server, each user has a configuration file with all the usual stuff: UI customizations, last-used state, etc. It is actually a separate small Lotus Notes database, one-per-user, stored locally AND replicated/synced with the server and with any other clients where the user signs-in. Very helpful to have the identical user experience on every computer, AND allow every computer to support multiple users.

Assuming the database is on an accessible server, Lotus Notes also allows storing of the client app PLUS user config on a USB stick, so essentially any computer can be used as a temporary client.

As Ray Ozzie, creator of Lotus Notes, likes to say, the devil is in the details, so some of this is not trivial to implement. For instance, Lotus Notes does field-level replication/syncing, which requires that every replica store a timestamp for each field. It gets deep because so many users (tens of thousand in some cases) could be replicating, and the "identical" database could be on hundreds of servers.

Not suggesting MC become Lotus Notes, but there are enough similarities that some of Ozzie's ideas might be useful.

[MusicHawk]

JustinChase: Regarding the dual-user situation, my library's Keywords get quite specific, and combined with "reasonable" rating of every track, it all works out.

For instance, during the summer my wife likes to sit in the patio and listen to music with Keyword "tropical" -- which means whatever she wants it to mean, but is assigned to all the tracks she wants to hear in this situation.

Another Keyword is "dinner", great background for a dinner party. Pre-dinner we play Keyword "cocktail". Etc.

Songs we think are worth playing are rated 3, 4 or 5 (1 and 2 are used to identify songs that we don't want to delete but don't want to hear either). We rate as 4 or 5 songs that are undeniably good, no debate. We rate as 3 songs that are appropriate just in some situations. Rating is always combined with Keywords to define the situations via smartlists. So the Tropical list is songs with this keyword AND rating of 3 or higher. Same with Dinner, and Cocktail. But when we just want to play lots of "good" music, the smartlist omits 3 and selects only 4 or 5 rated songs. So, a so-so 3-rated "tropical" song is only played in that situation, but not for general listening, while a 4- or 5-rated "tropical" song is good enough to hear anytime (and quite likely also has several other Keywords to further categorize it. This method works fine 99% of the time.

These comments might be a deviation from the thread, or maybe not, since playlists/smartlists are probably the core of user-specific use of MC. I find it much easier -- a one-time task, usually -- to assign suitable Keywords to every track, then use smartlists, than to keep diddling with ratings OR contemplate each user doing individual tagging.

[newsposter]

yah, but WHY the need for control?  What problem are we trying to actually solve here or are we in search of new 'features' because everything else has already been done?

And yes, I know what can be done with a fine-grained level of playback control, but is it really a problem in need of a solution?

I'm of the opinion that full-function remote control applets for Android, WM, and iPhone/iPad are of higher importance.

[glynor]

yah, but WHY the need for control?

Porn.

I jest (kinda).  There are LOTS of reasons to want access controls, particularly in a professional environment, and there are lots of reasons you might want to keep some content private.  Beyond that, there are UI reasons to want to keep the Views presented to the users simple, while maintaining the "admin" flexibility of having lots of specialty views as a power user.  Plus, I might want to allow my friends and family to rate songs or change tags here and there, but not mass-delete large swaths of files from the system.

Right now, all copies of MC are equal on the network, and this has a lot of data security implications beyond just hiding content from certain users.

But, you know... That, and porn.

[Matt]

yah, but WHY the need for control?  What problem are we trying to actually solve here ...?

This is a good question.

I think it would be nice if, when my daughter uses a laptop to watch television, she only sees her shows.  And when I sit down at the couch, I don't see Sesame Street (unless it's been a really long day).

[newsposter]

Are we all Steve Jobs now?  And what kind of idiot places her digital porn collection in a place where they have to worry about people stumbling across it?

Before you know it someone here is going to make a case to support all kinds of DRM and upstream reporting to the adware servers too.

[newsposter]

view filters based on personal playlists will take care of hiding sesame street (or rescue me).

[Matt]

view filters based on personal playlists will take care of hiding sesame street (or rescue me).

Could you explain?

You can configure the Television views in Theater View, which I've done.  But the Standard View 'Television' view still shows all programs.

I could probably use Access Control on each client, but then isn't that basically what we're talking about?

[glynor]

yah, but WHY the need for control?

How about this use case?

Say I want to use MC to manage media files and documents for a workgroup in an office.  All of our data files are stored in a central server on a SAN, where we all have separate logins and separate permissions.  Most of the assets on the server (images, movies, sound clips, illustrations, and InDesign documents) are shared, and can be used by everyone in the office.  However, some of the content we work on is private, containing unpublished data for our clients, some of it might be covered by NDA, or some of it might have serious industrial espionage liabilities.  In this case, we'd need a system where certain assets in the library can be "shared" and certain ones can be "private" to individual users or groups of users, but have them all searchable via the same digital asset management system.

Even if you ignore wanting to block certain users from just viewing or using an asset in a pro environment, there are easy use-cases to make for access controls at home (besides porn).

For example, maybe I want to be able to manage all of our media from one centralized location as the "admin".  However, there is a sub-set of my music, images, and video files that really "belong" to my wife (and maybe eventually my kids), and I want HER to be able to manage those files.  However, I DON'T want her to be able to accidentally go into the system and Control-A and accidentally change the Artist tag on every single music file in my library to "?" (this actually happened to me once a year ago, she was trying to change the tag on just one song, and "accidentally the whole thing").  So, maybe I want her to have permissions to make changes, but have them be limited in some way (only to "her" files, or maybe allowing changes to no more than 50 assets at once, or something).  Maybe I want to allow her to change certain "basic" tags (Rating, Artist, Album, Track #, Name, Series, Season, Genre) but not delete files or change other more technical tags (dates, serial numbers, notes, file names, etc).

[newsposter]

and, slowly, you're making the case for the use of a 'real' OO database behind media server.

Rather than patching in user account and permissions support on the top user layer, it might be better implemented at the lowest levels.

Anyone who has done serious work with a CMS (and this appears to be the road that JR is taking MC) knows that a properly architected database as a repository of not just metadata but also permissions, stored queries (views, playlists, etc) is of prime importance.  The database does not have to hold the media objects as blobs (although it certainly could) but everything else needed to run the CMS (oops, Media Server/Library) needs to be in there along with provisions for redundancy, backup, and recovery.

Let the database engine handle things like permissions and views.  Let MC handle the playback issues.

[glynor]

Anyone who has done serious work with a CMS

I have.  We have a number of very expensive real digital asset management systems at my company.  They all suck compared to MC, despite costing hundreds of thousands of dollars.

A not-trivial reason for their "suck" is the open and non-specific nature of the database back-end.  There is a good reason that some of the premiere digital asset management systems out there will NOT plug into commodity SQL and Oracle systems except for at the very high-end (Cumulus for example).  I'm not talking about building a system that is able to handle 1000's of queries simultaneously from hundreds of users spread across a variety of different systems.  I'm talking about managing assets for a family or a workgroup of 5-15 people.  As MC's developers have explained before, those enterprise class database systems were designed with different targets and different types of access in mind.  They very well may not be a good fit.

I, personally, don't have any idea how flexible or inflexible the J River database back end is currently.  Frankly, how they implement the system technically in the background is irrelevant to me (that's for them to decide).  I'm just responding to the question of why it is needed.  I think there IS a market for these types of tools in a small professional environment where enterprise class DAM systems are WAY overkill, and where the rest of what is available is all JUNK compared to MC.  Even if you ignore these potential customers, though, I think that there is a viable use-case to be made for simple home users in the "traditional" JRiver high-end media player software market.

[newsposter]

JR wouldn't have to develop the engine.  Just make use of an established one with the needed features.

I'm not talking about something like an Oracle or even a MySql.  Something much smaller that internally supports the user account, permission, performance, and recoverability needed by MC.

Encryption would be nice as well.  If JR is going to go through the effort of establishing user accounts/permissions they may as well start encrypting the metadata too.

It would be nice to have an option to keep all tags/metadata EXTERNAL to my media files.  Continue to support the embedding of ID-whatever tags, but being able to setup and maintain a standard structure of metadata for all types of media files regardless of what their embedding capabilities are would be an eye-opener for a lot of people.

Once Upon a Time, I brought up this little dB engine as a candidate.  I am sure that there are others out there.

http://www.1-software-source.com/index.html

Pretty low cost to enterprise license for development, NO distribution or run-time costs.  Doesn't explicitly support Mac (sorry) but does support Wintel and Linux.  Could be a door opener for adding platform support.

Might be time to reexamine it.

[jmone]

There are endless reasons why users will want to control access to MC, and yes this is the stuff DB does well and has done for ages.  If going down this path, MC would need to look at a scema that supports:
1) Ability to create User Accounts
2) Ability to group User Accounts into "User Groups"
3) Support the concept of various Permissions "See / Open / Edit / Delete / Admin" across all objects (Features, Options, Structures, Views, and of course content iteself)
4) An I'Face to apply the Permissions by User Group to the Objects

I'm not busting a gut for this but I would use these features and it is a logical extension of the play anything / anywhere concept (and I've insight into how MC currently works) but if not using an existing DB this could be a very big task to implement well.  

Thanks
Nathan

[JustinChase]

Are we all Steve Jobs now?  And what kind of idiot places her digital porn collection in a place where they have to worry about people stumbling across it?

I think Glynor has answered this quite well already, but about this point...

I have all of my media stored under separate mapped drives for audio, video, images and documents, and the pron is stored in it's own sub-folders in the same place I store all my media; why wouldn't I want it there?  No one that lives in my house has a problem with it.

however, my Mother comes to visit from time to time, and I certainly don't want to have to move 200 gigs of files to a hidden location for the 7 days she's here, and I don't want to go in and edit all the view schemes to block the content, or create/update a "safe" library for these 7 days either.

I want to tell her to log in as Mom, and she gets access to most stuff, with simple to use views and playlists, and have it automatically updated for changes to the rest of the media, so she can see the recent pictures we've taken, or TV shows we've recorded.

having a separate user/profile for family or guests or party or whatever solves this very nicely and easily; even if I am an idiot

[HTPC4ME]

Thank GOD!

Personally i dont care which choice 1 or 2.. as long as my 9 year old son from now on will not have access to my PG-13, R and Unrated Material.

And what kind of idiot places her digital porn collection in a place where they have to worry about people stumbling across it?

personally porn is the worst case. i have pics of partying times (not porn) that my son or family members Shouldnt be able to see.. These are just for my gf and friends.. same goes with my comment above, PG-13, R, Adult Comedy etc, this is one big reason ive not shared my library with anyone.. they would have access to all my stuff and there kids could stumble upon it, tv shows with mature content, movies, audio books, etc.

Thanks For Listening.. And Im Beyond Happy, This Issue is finally Getting Looked At, And Hoping soon I'll be able to give my son and friends and families, there own libraries, That I ALLOW THEM to have.

Which brings up another point... There are some people i'd like to share some of my library with, and they may not know my personal life or my son(close online friends that ive never met in person) I don't want them having access to pics or vids of my son, myself or Gf, etc.

[flac.rules]

I'm right there with you, Matt.  Having multiple libraries can be useful for completely different data sets that you'd never use simultaneously.  However, maintaining separate libraries is really a challenge if they actually reference similar (or identical) media files, and seems like a lot of work for limited gain.

I've been pulling for a "true" network server enabled version of MC for a long time.  If this is one step down that road, I'm all for it.

In the end, I think what we need is a solution where one machine can run and serve a "unified" library, which can be accessed by different users (by "users", I  mean BOTH different people with different permissions AND devices with separate "view" needs).  All changes done by remote copies of MC need to be able to be saved back "transparently" to this master database.  The current Library Server system is close, but is still effectively read-only for network machines (I know you can now manually sync changes back, but this is still clunky and prone to failure).  Plus, some of the functionality seems duplicated via the DLNA stuff, Theater View, and the WebRemote/WebPlay stuff.

This would be an opportunity to unify all of that with a single UI paradigm.  Obviously it isn't going to happen all at once, and I'm patient.  But I really think separating the functionality into separate and distinct libraries is going to hamstring the capabilities of the system in the long-term.  It might get a few people to where they want to be quicker right now, but for the long view, I really think it would be quite limiting.

Hmm, I Think you have convinced me, the main point is getting different sets of settings and files over to different users/devices/groups of users. I see now that you can do this just as well with alternative #2 as alternative #1, maybe even better.

I really like the way the program is taking, MC15 has had a lot of solid progress when it comes to getting a more server-client-based system. Keep up the good work!

[MrHaugen]

FINALLY J River! It's about time you take access control seriously

I don't understand why people ask WHY this is important? Do you have no imagination?

Think of a house filled with small Media PC's.
- You'd like to restrict tag/playlist/scheme writes to your library (for visitors, children etc)
- You could have an Audio only logon on the bathroom for Music only
- You could share all your movies, and music, but blocking your personal Pictures out, in your apartment you live in with your friends
- You could share all media, but blocking all writes to the library, so this friends don't mess up the music (the primary reason why I don't share/use library server today)
- You can actually add ALL you're movies to the library. Also your porn. Yes, people still watch porn. Strange, right?

Businesses
- They could do the same thing. Restrict content for the type of customers. Play only commercial movies in the lobby, and let the customers play with other Tutorial/commercials on another PC. Block write from all unsecured sources.


How to go about it?

I think it's VERY nice that this is finally getting some attention. But you have to think of HOW this is supposed to be used as well.
- Think of how to filter the different media, playlists etc. Granularity of the filtering should also be considered.
- Think of how to change between the accounts. You need a fast user switching ability in Theater View and Standard view. With password protection (on screen keyboard popup?)
- The ability of locking down the Theater View would be rather essential for the use in some cases.

I'm sure there is other things you'll have to consider, but I'll add more as I can think of any.

[HTPC4ME]

Businesses
- They could do the same thing. Restrict content for the type of customers. Play only commercial movies in the lobby, and let the customers play with other Tutorial/commercials on another PC. Block write from all unsecured sources.

ive asked about this before, be great for our small business in the war room... anyway we can get an edge over other companies(especially corporate) personalized playlists (audio and video)for our customers.

[MrHaugen]

The most obvious way of dealing with this (at least to me), is to use some sort of Access Control Lists (ACL). Just like you have in windows server environments with a Domain Controller (with the ALC's), and the servers who acts like clients. A Windows domain treats all objects with it's own ACL, and gives permissions based on this. The downside to the Media we use, is that some of the files are not that tag friendly, AND it could pose a security risk, if the ACL's could be tampered with in a TAG editor for instance.

- If I was to design this, I would start of by deciding where the changes was allowed from. You'd have some security issues if it was allowed to edit ACL's from all clients. So I would let the Media Server act like a Media Controller Server as well. Possibly add some unique identifier which the clients check against, before giving access to the media.  

- I'd set the ACL's to all media objects. It would be troublesome to attach this ALC's directly to some media types, with the exception of things that are controlled by you. Like View Schemes, Play lists etc etc. Because of this, you would probably need to add a secondary database for the objects  ACL's, or to incorporate this into todays library database.

- The clients could either check against this ACL's for every access, or there could be a timed out ticket on each object, so you don't require to get the ACL's each time. To speed things up, there could also be discussed if the whole database with ACL's, or parts of it, should be synchronized with the clients, so they can access it faster (if it's necessary at each view change etc).

- There also have to be some sort of Inheritance on media added. Or else there would be way to much work for each media file you add. You could consider adding inheritance based on folder structure and some of the Library Fields (for instance Media Type, Media Sub Type etc). For Playlists and Views the inheritance could be set on each level.

What should also be considered, is to add the ability to connect certain libraries to each group or user. That would provide users with the option to either have a HUGE library for all members of a family or company, where media or playlists etc are restricted and not shown to some groups or individuals, to make the library SEEM more personal (and secure of course). OR you could make a personal library for each user, so there is a true user based experience, AND the security is maintained. The last option should not ever be considered as an alternative to ACL's and real user access control though.

As I also have mentioned earlier, there are things like user switching that have to be considered. Locking down MC in Theater View can be crucial for adding this in a business environment. To switch users fast from the main menu, can be crucial for every day Media terminals on kitchen, the bathroom etc, where people want to log into their "personal library" to get their own playlists to play, and Views to view.



I'll add more later on if I can think of any more.

[Alex B]

While this massive brainstorming continues, I'd like to re-request a small addition that would make the "multi-"user experience a bit nicer:

- An option to promote one of the libraries to be the default library that would be loaded on startup.

I often forget to load our usual main library back before I close MC on our HTPC. When another user starts MC the library may be one of my test libraries or, for instance, MC may try to load the server library from my absent laptop.

This seems like a no-brainer to me. I have requested this a few times and others have agreed that it would be a good feature.

[zxsix]

While this massive brainstorming continues, I'd like to re-request a small addition that would make the "multi-"user experience a bit nicer:

- An option to promote one of the libraries to be the default library that would be loaded on startup.
,
I often forget to load our usual main library back before I close MC on our HTPC. When another user starts MC the library may be one of my test libraries or, for instance, MC may try to load the server library from my absent laptop.

This seems like a no-brainer to me. I have requested this a few times and others have agreed that it would be a good feature.

That can be solved by specifying the specific library in the shortcut that you launch MC with.

[Alex B]

I know that, but a simple option in the library manager would be easier and accessible inside MC. Not all users are comfortable with tweaking shortcuts.

That said, I might actually tweak the shortcut now. I just need to find the correct command line first. I think it is somewhere in the JRiver Wiki...