PDA

View Full Version : Multiple Profiles?



Randall
2005-08-10, 11:23
Howdy dev team. Question. I'd like to see the squeezebox allow different profiles. Why not? For example. Say I personally have 50% decent songs while the other 50% are songs that have explicit lyrics in which I really wouldn't want others to hear during a party.

If I could turn on the squeezebox and choose a profile that can only see the half of the library that I wouldn't mind my mother hearing - that would be awesome.

Please Slimserver dev team, PIMP my Squeezebox!

Any ideas?

Randall

kdf
2005-08-10, 11:31
Quoting Randall <Randall.1tk9jo (AT) no-mx (DOT) forums.slimdevices.com>:


> If I could turn on the squeezebox and choose a profile that can only
> see the half of the library that I wouldn't mind my mother hearing -
> that would be awesome.

add your vote, and/or your email to the cc list:

http://bugs.slimdevices.com/show_bug.cgi?id=825

-kdf

kdf
2005-08-10, 11:38
Quoting Randall <Randall.1tk9jo (AT) no-mx (DOT) forums.slimdevices.com>:

> Howdy dev team. Question. I'd like to see the squeezebox allow
> different profiles. Why not? For example. Say I personally have 50%
> decent songs while the other 50% are songs that have explicit lyrics in
> which I really wouldn't want others to hear during a party.

actually...if this was ALL that you wanted, you could make this work right now:

move all your unsafe songs to a separate directory tree.
create a shortcut to this directory tree in the safe folder.

point your music folder setting to the safe folder and let it scan.
find c:\program files\slimserver\server\slimserversql.db and make a copy

now, delete the shortcut to the unsafe stuff and do a rescan, with clear library
checked.
then make another copy of slimserversql.db.

just copy over the right db files, and restore or delete the shortcut to match.

complicated, but immediately workable. If your library is not that huge, and
you dont mind scan times you can forget about copying the db and just create or
delete the shortcut at will and go into server settings, check "clear library
contents" and click rescan.

-kdf

Michael Amster
2005-08-10, 11:50
Randall wrote:

>Howdy dev team. Question. I'd like to see the squeezebox allow
>different profiles. Why not? For example. Say I personally have 50%
>decent songs while the other 50% are songs that have explicit lyrics in
>which I really wouldn't want others to hear during a party.
>
>If I could turn on the squeezebox and choose a profile that can only
>see the half of the library that I wouldn't mind my mother hearing -
>that would be awesome.
>
>Please Slimserver dev team, PIMP my Squeezebox!
>
>Any ideas?
>
>Randall
>
>
>
>
Build playlists...

Randall
2005-08-10, 20:49
No... Build Profiles. I have 6 squeezeboxes in the house. I have 4 people with access to them at all times. I'm sure I'm not the only one that wants to control the devices this way.

Would you let someone other than yourself log into your computer as yourself to browse around and see what they can find?

kdf
2005-08-10, 20:59
On 10-Aug-05, at 8:49 PM, Randall wrote:

>
> Michael Amster Wrote:
>> Randall wrote:
>>
>>> Howdy dev team. Question. I'd like to see the squeezebox allow
>>> different profiles. Why not? For example. Say I personally have
>> 50%
>>> decent songs while the other 50% are songs that have explicit lyrics
>> in
>>> which I really wouldn't want others to hear during a party.
>>>
>>> If I could turn on the squeezebox and choose a profile that can only
>>> see the half of the library that I wouldn't mind my mother hearing -
>>> that would be awesome.
>>>
>>> Please Slimserver dev team, PIMP my Squeezebox!
>>>
>>> Any ideas?
>>>
>>> Randall
>>>
>>>
>>>
>>>
>> Build playlists...
>
> No... Build Profiles.

were you asking for ideas, or merely giving orders? if it's the latter,
you can take a number...
http://bugs.slimdevices.com/show_bug.cgi?id=825
-kdf

Bruce Hartley
2005-08-10, 23:57
I don't know about the whole profiles thing, maybe that's overkill.
But I would like a way of segmenting the music library.

Particularly I would like a way of limiting the choice that the random plugin could make, but I guess that's one for the 3rd party forum.

Cheers,
Bruce.

Randall
2005-08-11, 07:34
were you asking for ideas, or merely giving orders? if it's the latter,
you can take a number...
http://bugs.slimdevices.com/show_bug.cgi?id=825
-kdf


He ordered me first!

dean
2005-08-11, 07:46
On Aug 11, 2005, at 7:34 AM, Randall wrote:
> kdf Wrote:
>> were you asking for ideas, or merely giving orders? if it's the
>> latter,
>>
>> you can take a number...
>> http://bugs.slimdevices.com/show_bug.cgi?id=825
>> -kdf
>>
>
> He ordered me first!

Now, boys, I don't care who started it. Don't make me pull this car
over!

Michael Amster
2005-08-11, 10:48
Randall wrote:

>kdf Wrote:
>
>
>>were you asking for ideas, or merely giving orders? if it's the latter,
>>
>>you can take a number...
>>http://bugs.slimdevices.com/show_bug.cgi?id=825
>>-kdf
>>
>>
>
>
>He ordered me first!
>
>
>
>
I did not see the issue until you explained the user/squeezebox control
problem. I think segmenting your music by access control and then
pointing different squeezeboxes at different root directories that
contain the links to the different music by roles is the only solution I
see. I also think that the playlist/party mode plugin (that restricts
admin privs) is a solution. Not pretty, but doable. This of course
still implies build access control subdirectories and stuff, so DO THAT
WORK :)!

JJZolx
2005-08-11, 12:36
User profiles strike me as a feature that must happen at some point in time.

But the idea of multiple libraries is something that wouldn't have to depend on user profiles. It might be a browse level above Browse Music.

The question I'd have is how do you designate what is contained within a given library? Setting different music library root folders is one way, but would require quite a bit of creative use of links/shortcuts unless you accepted having multiple copies of a track in each library to which it belongs.

One approach I could see is having a "master" library with a single music folder like there is now, then creating a web interface where you could build a library by browsing the music directory and saying "Add to Library". This might also make (re)scanning easier, although when doing a scan you'd have to maintain library db links so that work done to create the custom libraries aren't lost.

fuzzyT
2005-08-11, 13:14
JJZolx wrote:

> But the idea of multiple libraries is something that wouldn't have to
> depend on user profiles. It might be a browse level above Browse
> Music.

true, it doesn't have to depend on user profile, but it helps. some of
the user issues that were driving the requests for multiple libraries
would be automatically solved if libraries were attached to users. i'm
thinking of the kids music polluting the parent's library, adult themed
music being accessible to kids, roommates who don't want to expose their
libraries to each other.

i guess in my mind the concept of library has more to do with ownership
and management responsibility than anything else. it's /personal/, kind
of like the data on your iPod, cellphone or PDA.

given this, the idea of having your own music directory makes sense.
OS-level rights to that directory can easily exist. differences in
tagging and format preferences can be honored. and segregation in the
web interface where playlists and favorites can be managed also seems to
make sense.

although libraries could be useful for genre segregation we already have
mechanisms for that.

> The question I'd have is how do you designate what is contained within
> a given library? Setting different music library root folders is one
> way, but would require quite a bit of creative use of links/shortcuts
> unless you accepted having multiple copies of a track in each library
> to which it belongs.

overlap may well occur, but could be managed a number of ways. as you
point out, rather than a copy being placed in more than one library
aliases could be used. as long as SS was adept at recognizing and
dealing with these it shouldn't pose a problem. alternatively the
duplicates (and near duplicates) could either be presented distinctly or
merged in the UI by some sort of rule.

> One approach I could see is having a "master" library with a single
> music folder like there is now, then creating a web interface where you
> could build a library by browsing the music directory and saying "Add to
> Library". This might also make (re)scanning easier, although when doing
> a scan you'd have to maintain library db links so that work done to
> create the custom libraries aren't lost.

the problem of persisting the library-to-track association on rescan and
wipes is one thing that got my thinking headed in the direction of
directory based libraries.

--rt

kdf
2005-08-11, 13:25
The server does already make use of the HOME environment for users in some OSes.
If the server were tweaked a bit to allow it to easily run as multiple
servers, the user profile slimply becomes a matter of running the server under
a different user, with associated prefs, library, db, etc. You can then use
existing plugins to block setup, etc. The SB2 can already be told which server
to use; likely just needs a bit more to allow selection of the port in order to
chose which of the servers on a given pc.

Trying to refactor the existing server to run multiple libraries concurrently
would probably end up being very similar to running multiple copies of the
whole server.

This can be done right now by simply using multiple pc's, so it seems to me that
this is really the core issue. users want to have to only use the one machine.
If this extends to insisting on ONE application, perhaps a wrapper then.

All the discussion so far is great, and keep it up. I just thought I'd toss in
what seemed to be as simple as psosible for the approach. It would have the
advantage of less waiting for it to become a reality.
-kdf

fuzzyT
2005-08-11, 14:31
kdf wrote:
> The server does already make use of the HOME environment for users in some OSes.
> If the server were tweaked a bit to allow it to easily run as multiple
> servers, the user profile slimply becomes a matter of running the server under
> a different user, with associated prefs, library, db, etc.

i don't think this would allow for users to access more than one library
in a blended mode.

also, wouldn't this increase overhead for system resources to load
multiple instances of all the server bits?

i'm thinking of multiple libraries all being in the same database, just
with tracks having a reference to the library that they belong to.

> Trying to refactor the existing server to run multiple libraries concurrently
> would probably end up being very similar to running multiple copies of the
> whole server.

in my mind, it's more like building in a new upper level bit of metadata
(like "genre") and then building the UI to support this structure. most
functions could work exactly as they do now, except that calls to the
track database would have an extra WHERE clause for library filtering.

server settings would be common to all users but with limited access to
administration i think that's probably ok. and per-player settings are
already supported.

and if you don't want to get hung up in tying it together with security,
then just consider library filtering to be a pref and let users choose
which to see.

> This can be done right now by simply using multiple pc's, so it seems to me that
> this is really the core issue. users want to have to only use the one machine.
> If this extends to insisting on ONE application, perhaps a wrapper then.

right-o on the one machine preference (or zero, truth be known). no
reason why each library couldn't be hosted centrally and share one SS
instance. some libraries could be expected to go offline and online
(laptop, portable drive or player). server would have to detect this,
but previous scans could be preserved in the DB if the device/path were
uniquely recognized.

> All the discussion so far is great, and keep it up. I just thought I'd toss in
> what seemed to be as simple as psosible for the approach. It would have the
> advantage of less waiting for it to become a reality.

ok. glad to know i'm (we're) not making you crazy. i don't know that
my vision of how this would work is the best, but it does seem possible.
and i am willing to wait for a really kickass implementation.

oh, willing to work within the limits of my time and capabilities.

--rt

kdf
2005-08-11, 15:01
Quoting ron thigpen <ron (AT) fuzzsonic (DOT) com>:


> also, wouldn't this increase overhead for system resources to load
> multiple instances of all the server bits?

well, I think I'm just getting the impression that demands for how this must
work will end up causing the one instance to double up on so much already. Its
a given that once such a feature is created, there will be a user out there who
will demand that it works in every different way possible. Share some files,
not others, share prefs, not others. User defined access to players, swappable
on the fly, admin lockouts etc. Just about any feature you name will have at
least one person who will say that its absolutely required. The idea of two
separate servers just cuts to the chase, though admittedly bars shared
libraries on the fly. You'd have to use symlinks.


> i'm thinking of multiple libraries all being in the same database, just
> with tracks having a reference to the library that they belong to.

it all depends on how much isolation is required to satisfy the majority of
users. It may be enough to simply obey user permissions on a per-directory
basis. A bit complicated on systems that dont really have very good multi-user
permission control.

> in my mind, it's more like building in a new upper level bit of metadata
> (like "genre") and then building the UI to support this structure. most
> functions could work exactly as they do now, except that calls to the
> track database would have an extra WHERE clause for library filtering.
>
> server settings would be common to all users but with limited access to
> administration i think that's probably ok. and per-player settings are
> already supported.

I agree in principle. I think I'm just gunshy after hacking my way through a
miserable attempt to handle multiple folders (bug 607). Just trying to make
snse of that was headache enough to keep me from pondering any effort on my
part on the code for this kind of change.


> right-o on the one machine preference (or zero, truth be known). no
> reason why each library couldn't be hosted centrally and share one SS
> instance. some libraries could be expected to go offline and online
> (laptop, portable drive or player). server would have to detect this,
> but previous scans could be preserved in the DB if the device/path were
> uniquely recognized.

true enough. part of my thinking was also influence by the current server limit
on db access. sqlite can't handle concurrent connections, so a single db is a
thing of the future. Right now, this discussion has no timeline, so my main
angle was something near term. eventually mySQL use will allow this kind of
thing.

> ok. glad to know i'm (we're) not making you crazy. i don't know that
> my vision of how this would work is the best, but it does seem possible.
> and i am willing to wait for a really kickass implementation.
>
> oh, willing to work within the limits of my time and capabilities.

good to know. I'm not fully into this side of things myself. A lot of the db
stuff is out of my league. In the interest of disclosure, I think my personal
motive is avoiding a monstrously complex beast that is trying too hard to give
everything to specific individuals and spreading too thinly on the core
design requirements. Of course, I don't know exactly what those are, so I tsick
with my own sense of confusion as a limit. It was a full-time job keeping on
top of all the activity. Since I already have a full-time job, I gave up on
keeping up with every path. :)

-kdf

-kdf

JJZolx
2005-08-11, 15:09
i'm thinking of multiple libraries all being in the same database, just
with tracks having a reference to the library that they belong to.

> Trying to refactor the existing server to run multiple libraries concurrently
> would probably end up being very similar to running multiple copies of the
> whole server.

in my mind, it's more like building in a new upper level bit of metadata
(like "genre") and then building the UI to support this structure. most
functions could work exactly as they do now, except that calls to the
track database would have an extra WHERE clause for library filtering.

server settings would be common to all users but with limited access to
administration i think that's probably ok. and per-player settings are
already supported.

I see the use of multiple libraries similarly, but as a kind of half-step toward user profiles. My suggestion is that implementing multiple libraries would satisfy the majority of the reasons that people ask for user profiles. The login, user interface prefs and scanning prefs aren't as critical, but need to happen some day.


and if you don't want to get hung up in tying it together with security,
then just consider library filtering to be a pref and let users choose
which to see.

From what I've read in the requests the security aspect is an important part of the need for separate users/libraries. You don't want the kids getting into the adult comedy albums, or you're having a party and you want to restrict what music the guests may play. Perhaps implement the ability to lock a particular Squeeebox into a single libary from a password protected server setup.

wr420
2005-08-11, 17:03
>
> well, I think I'm just getting the impression that demands for how
this
> must
> work will end up causing the one instance to double up on so much
already.
> Its
> a given that once such a feature is created, there will be a user out
> there who
> will demand that it works in every different way possible. Share some
> files,
> not others, share prefs, not others. User defined access to players,
> swappable
> on the fly, admin lockouts etc. Just about any feature you name will
have
> at
> least one person who will say that its absolutely required. The idea
of
> two
> separate servers just cuts to the chase, though admittedly bars shared
> libraries on the fly. You'd have to use symlinks.
>

They have already got their own custom network transport why not just
expand on it and create the SOS(Slim Operating System) and SFS(Slim File
System).
It would probably be easier in the long run;)

The information contained in this e-mail is strictly confidential and for the
intended use of the addressee only; it may also be legally privileged and/or
price sensitive. Notice is hereby given that any disclosure, use or copying
of the information by anyone other than the intended recipient is prohibited
and may be illegal. If you have received this message in error, please
notify the sender immediately by return e-mail. All e-mail sent to this
address will be received by Acacia Pacific Holding's e-mail system and is
subjected to archiving and review by someone other than the recipient.

Acacia Pacific Holdings has taken every reasonable precaution to ensure that
any attachment to this e-mail has been swept for viruses. We accept no
liability for any damage sustained as a result of software viruses and
advise you carry out your own virus checks before opening any attachment.