View user's private media when user is selected.

[donpaul]

When I switch to a different user, that user's private media is not displayed when browsing; I have to also click options, and select the user. I think it would be more fluid to see a user's private media when that user is selected. An option to view the user's private media when the user is selected would be fantastic.

[donpaul]

It would be even better if the option could be picked for each orbiter.

[jondecker76]

I would have to agree with this request. I don't see the point in having to select it from options each time when user authentication is already handled elsewhere

+1

[colinjones]

I see the point, however one issue with this would be that then someone's private media would always be visible ... it no way to turn it off without having a "dummy" user to switch to..

[donpaul]

I see your point, but that is really only the case in a single user environment (so why have a "user" anyway). But, in my case, the default user for public areas is "Guest". Guest is all public media, and is used since we entertain. The default user in our bedroom is the wife. The default user on my laptop orbiter is me... etc, etc. If someone where to switch to a user (Don for instance) then Don's private media should be available as well. Don could of course choose to use a pin if he really needed his media private.

In my situation, all family members have their private media so that the 100's of movies are easier to browse. I use a pin, and the rest of the family doesn't care if someone looks at their private media; I just want to organize the media so that I am not looking at 300 cartoons from my kids media collection, and my kids are not looking at my 100's of my adult movies ;-) And I know it can be done through tagging, but seriously that does not solve the issue. I may want to look at dramas, just not the 300 drama's in my wife's collection.

I can see a big need for this, especially once LinuxMCE is more mainstream. Especially for organizations, like a daycare or school. Users could actually be by use... such as teachers, age groups, classrooms, purpose, etc.

Also, if it were an option, then someone can choose whether or not to view private media when the user is selected.

[jondecker76]

collinjones:

if by default private media is shown for the signed-in user, you could still use the current system to not show media for that user. The only difference would be that by default it is shown.

Of course, the best solution would be to use persistance across reloads so that when you have it set up on an orbiter how you like it, then it will continue to be just how you like it.

I would recommend going to trac and filing a bug report/feature request to make this persistant across reloads. Then, LMCE could ship the defaults just how they are now, but if on orbiter "A", you filter your media to only show Public and User_1 media, then it will continue to do so even after Reloads. On orbiter "B", you may choose to only show User_2 media while that user is signed in, and so on.

[colinjones]

jon - I'm not arguing the point really, there is a security issue there, but I accept that this would be mitigated by the suggested "guest" user, so I'm fine with that. As for logging the ticket.... I'm more interested in the ticket I logged for sort order persistence I logged over a year ago... not going to clog things up with another one that I'm not particularly interested in

[jondecker76]

point being that persistence across reloads needs looked into eventually - whether it is sort order, filtering, or some other feature that someone will eventually get sick of doing manually each time it is needed. Hopefully this thread will pick up more support for that and we can begin discussing the best way to go about it.

Off the top of my head, I could envision a simple table addition, something like pluto_main:orbiter_persistance, with the fields FK_Orbiter, FK_User, Key, Value
Then you can store an arbitrary number of key/value pairs as needed. For example, lets assume that we are dealing with PK_User=1, and PK_Orbiter=133 - and we want to persist sort order. We can then store into the orbiter_persistance table:
FK_User     FK_Orbiter     Key     Value
1               133              sort     performer
2               133              sort     title

etc...
In the above example, user_1 will have a performer sort, and user_2 will have a title sort. If no key/value pair exists in the table, then defaults are used. For persistence, these values only need to be loaded from the database when the orbiter plugin initializes, and the table must be updated when anything changes (sort order, etc...)

Anyone else have some suggestions for an elegant way to handle this?

[colinjones]

agreed completely! that's exactly what I would like to see... I think the additional table is a great way of doing that.

[chriss]

Anyone else have some suggestions for an elegant way to handle this?

It might be a good idea to not restrict the table to the orbiters but make it something like pluto_main:plug-in_persistence, i.e., any plug-in should be able to store persistence information. This would be useful for e.g. timer plug-ins, home automation plug-ins etc.

Just my 2c
/chriss

[jondecker76]

excellint idea - we would only need an additional field FK_Device to store the plugin device number. Actually, you store persistent data for any device (plugin or not) with this method.

It actually makes sense to make an actual persistence_plugin, with methods to easily store and retrieve persistence data from the database. This is something I can work one once they quit beating me up at work (i won't have a day off for at least another couple of weeks)

[hari]

we have device data for persistent data. So I wonder if a "generic" plugin to store additional data sets makes sense. The info plugin already provides commands to get and set device data.

Linking a "preferences" (more generic than orbiter persistance) tables to users and orbiters would be a good idea indeed.

best regards,
Hari