Re: Re: [Slimp3-checkins] CVS: slimp3/server/lib/SliMP3 Client.pm,1.42,1.43 Playlist.pm

Apologies in advance for when everyone gets this message for the second time whenever the mail queue to the internet decides to let it go.

> -----Original Message-----
> From: dean blackketter [mailto:[email protected]]
> Sent: Wednesday, February 19, 2003 9:41 AM
> To: Robert Moser II
> Cc: [email protected]
> Subject: Re: [Slimp3-checkins] CVS: slimp3/server/lib/SliMP3
> Client.pm,1.42,1.43 Playlist.pm,1.159,1.160 Prefs.pm,1.91,1.92
> Setup.pm,1.80,1.81
> 
> 
> Hey Robert,
> 
> Could you give a little background on what this change is?

Sure, this makes the current playlist of all clients persistant across server restarts.

So, you add a bunch of songs to your playlist, decide to update from CVS, so you stop the server, update, then restart it.  The player would still have all those songs in its playlist.  The current song, and the shuffled order of the songs is not preserved.

What happens is an .m3u file is created for each player in the Saved playlists directory.  This file is named by taking the client id, changing the : to an _, prepending __ so that the playlist won't show up in either interface, and appending .m3u to the end.  So, a player coming from 192.168.1.100:3843 would have a playlist named __192.168.1.100_3843.m3u

Each time the playlist changes, the new playlist is written out to the file.  This shouldn't be too much of a burden, since the m3u format is pretty much just a dump of an array to a file.

It just struck me last night that all the pieces to do this were present:
1) generic playlist writing function (put in by me)
2) ignoring /^__/ in the saved playlist directory (Dean)
3) executecommand callbacks (Dean again)

I did have to add a few callbacks to capture the changed playlist correctly.  'playlist' 'load' and 'playlist' 'add' don't complete right away, so I needed to capture the load_done and add_done events.  And when you sync you modify the playlist without going through executecommand, so I had to fake it with a 'playlist' 'sync', just like Dean did with the 'opennext' event.

And of course since it is possible that this behavior might not be desired, I added a preference (modified through the server-behavior page) to turn it off (on by default).

And it works for stream clients as well (although that might be ugly behind a NAT).  You still need to hit play on the server though.

Robert

> On Tuesday, February 18, 2003, at 09:23  PM, Robert Moser II wrote:
> 
> > Update of /cvsroot/slimp3/slimp3/server/lib/SliMP3
> > In directory sc8-pr-cvs1:/tmp/cvs-serv411
> >
> > Modified Files:
> > 	Client.pm Playlist.pm Prefs.pm Setup.pm
> > Log Message:
> > Added ability to persist playlists between server restarts.
> >
> > Client.pm - added commandCallback() to save playlist whenever it  
> > changes
> > playlist is loaded in newClient().
> >
> > Playlist.pm - added calls to executeCommandCallback in load_done,  
> > add_done,
> > and sync.
> >
> > Prefs.pm - added default for 'persistPlaylist', and onChange handler
> >
> > Setup.pm - added entry for setting 'persistPlaylist'


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/FpY02D/vN2EAA/xGHJAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/