PDA

View Full Version : Non-clobbering Play function



Christopher Snell
2005-03-14, 14:45
Background: We use our Squeezebox in a large retail store. The
employees all know how to use the web interface to add songs.
Occasionally, the boss man likes to come in and play some of his songs
but he doesn't want to wait for the hours of already-queued songs to
finish, so he picks his album and clicks the "play arrow". This
clobbers the already-running playlist that took the employees so much
goof-off time to create. They get frustrated and quit adding to the
playlist because of the futility.

Feature request: We would like to see a feature to add a
(song/album/artists/folder) to the playlist but add it first, before
everybody else's selections. Ideally, this would be
password-protected but we'd settle for just having the functionality.

How is the playlist managed within the server software? Does it
reside in a database or in memory? Maybe I could add this
modification myself.

Thanks,

Chris

Marc Sherman
2005-03-14, 14:51
Christopher Snell wrote:
>
> Feature request: We would like to see a feature to add a
> (song/album/artists/folder) to the playlist but add it first, before
> everybody else's selections.

That feature already exists. It's called "insert", and it's mapped to
add.hold in the shipping Default.map file. You could change the play
mapping in Default.map from play to insert, and you wouldn't even have
to retrain your boss.

- Marc

JJ
2005-03-14, 15:59
> Feature request: We would like to see a feature to add a
> (song/album/artists/folder) to the playlist but add it first, before
> everybody else's selections. Ideally, this would be
> password-protected

Password protected? Hmmm...

This brings up a point I'd been wondering about - protecting things like
server settings from prying fingers (read: kids) through some type of
security.

Also, the ability for different users to have different interface
settings. Probably doesn't have to be user/password based - how about
just setting a cookie to identify different users? Say a user sets his
skin, whenever he comes back he sees the same skin, rather than having
this be a server wide setting? There are a few other interface settings
beside just skins that would probably be handy to be able to set on a user
by user basis.

Daryle A. Tilroe
2005-03-14, 16:27
Christopher Snell wrote:

> Background: We use our Squeezebox in a large retail store. The
> employees all know how to use the web interface to add songs.
> Occasionally, the boss man likes to come in and play some of his songs
> but he doesn't want to wait for the hours of already-queued songs to
> finish, so he picks his album and clicks the "play arrow". This
> clobbers the already-running playlist that took the employees so much
> goof-off time to create. They get frustrated and quit adding to the
> playlist because of the futility.
>
> Feature request: We would like to see a feature to add a
> (song/album/artists/folder) to the playlist but add it first, before
> everybody else's selections. Ideally, this would be
> password-protected but we'd settle for just having the functionality.
>
> How is the playlist managed within the server software? Does it
> reside in a database or in memory? Maybe I could add this
> modification myself.

I think you may be looking for something like these two
enhancement requests of mine from some time ago:

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

I don't think anything has changed in 6.0 but I have
not tried it yet. I guess I'm not even sure if they
will ever be implemented but you may want to comment
or vote if you think they make sense or if you see
a better way.

--
Daryle A. Tilroe

Aaron Zinck
2005-03-14, 16:38
> This brings up a point I'd been wondering about - protecting things like
> server settings from prying fingers (read: kids) through some type of
> security.

Give the "NoSetup" plugin a try:
http://www.herger.net/slim/detail.php?nr=428

> Also, the ability for different users to have different interface
> settings. Probably doesn't have to be user/password based - how about
> just setting a cookie to identify different users? Say a user sets his
> skin, whenever he comes back he sees the same skin, rather than having
> this be a server wide setting?

You can pass the skin selection in on the url. For instance:

http://slimserverip:9000/fishbone/

so a user could bookmark that page but it wouldn't change for everyone.