SQL playlists - was: New Rio Client - Stage 3 Complete

[Rob West]

Hello all,

I have been thinking about a playlist system that makes use of xQL/xPLHal
to
lookup the details of the next track. I guess this only makes sense if all
your track/album/artist/genre data is stored in an SQL database (along the
lines of JReceiver). Apologies for it being a bit long-winded :-)


Anyway, my theory is that you could then build a playlist by issuing SQL
queries: e.g.

select tracks.track_id from tracks, albums where tracks.album_id =
albums.album_id and album name like '%brand new day%' order by
tracks.order_id

for a whole album, or

select track_id from tracks where track_name like '%a thousand years%'

for a single track.

(Of course, these queries might return more matches than you bargained for,
so it would be wise to have an intermediate step where you could mark all
the matches that you actually wanted to append to the playlist.)


Once you have stored the query results in a "playlist" table, you
can use
the Rio's "end of track - stopped" message to trigger a
"play the next
track" message until you reach the end of the list. (Of course, you'd
have
to be careful that you didn't get stuck in a loop if the same track
appeared
in the list twice - but that's a fairly trivial problem to solve.)

Now, all this might seem like a "sledgehammer to crack a nut"
solution, but
it was based on the idea that the Rio doesn't actually have to store the
playlist which means:

(a) there should be no problems with the Rio running out of memory

(b) the playlist data is stored in an SQL database and is therefore
secure/searchable/modifyable etc.

(c) it would be possible for multiple Rios to play the same playlist at the
same time - either synchronised, or each at a different point in the list

(d) the playlist is dynamic in the sense that it can be modified in
"real
time" - e.g. at a party you could use it as a jukebox, where anyone
could
search for a track and append it to the currently-playing list.


My original plan was to implement this by extending JReceiver/MySQL -
allowing the creation/editing of the playlist via the web interface, but
I've put it on hold pending the release of xPLRio.net!

I suppose at some point in the future it would be possible to code the
"I've
finished the current track, I'll ask for the next track" behaviour
into the
Rio client, to save using xPLHal (and avoid the 1-2 sec delay between
tracks
that this causes).

Thoughts?

Rob.

----- Original Message -----
From: "Tony Tofts" <<a
href="/group/ukha_xpl/post?postID=mMdxIc828jxCoLbPUXSI1nX3iWUc8yVXTJrYz1YQ1pFB0_Zm0H_BCB1n9AOacOEBD5EqANN11DWlBA">tony@x...</a>>
To: <<a
href="/group/ukha_xpl/post?postID=L7wuehqrDvGMaE8zLYwuyjZyGfcANA60HO6R6YjHoDfy4SVOnBUs0gmMhBdIzTs63IpjkwZs4dvrpf7rP0eY">ukha_xpl@xxxxxxx</a>>
Sent: Saturday, February 14, 2004 5:20 AM
Subject: RE: [ukha_xpl] New Rio Client - Stage 3 Complete


> Hi all,
>
> Stage 3 of xPLRio.net (new name) is now completed.
>
> I now have a full menu/control structure in place :-)
>
> This includes using the alpha remote keys to narrow down the selection
lists
> to items starting with specific characters, and also a search facility
where
> you can type in a word or phrase to locate items. Inidividual items
can
also
> be removed from the 'now playing' queue. Shoutcast streams are in an
xml
> file, which is read into the database by the music scanner, to allow
easy
> editing of the list.
>
> Next up is stage 4 - getting some music to actually play!
>
> Some items I need some info/ideas on are:
>
> Still need an mp3 file with id3v1 tag
>
> Need info/suggestions on playlist format to use, do we use a standard
> playlist format or have our own?
>
> Many thanks
> Tony