[playlist] XSPFPHP

[Thomas R Bailey]

A basic philosophy and why I began this project.

I'm learning PHP so I was looking for a relatively easy project that
would allow me the opportunity to learn scripting basics. My son and I
have had an ongoing competition with embedding players on Myspace and I
thought it would be neat the use PHP to dynamically generate a playlist.
Especially if all I had to do to change the page was upload or delete
music. But after seeing the horrible performance of those I found at
LacyMorrow, and the two plus year old musicplayer.sourceforge project
and ohters I decided I could do better. I was going to write my own tag
reader but I found get_id3(). I was going to write my own flat file
cache but discovered that get_id3() already has caching. So far, to my
knowledge, this is the only id3-spiff playlist generator that uses a
caching mechanism making playlist delivery nearly instantaneous.

My home server and the project home page runs on an old Intel PIII
512Meg over 640K DSL and it generates the playlist as fast as the
browser can display it when it's cached. No other spiff generator can do
that. The sourceforge version titled: 'php-xspf-gen' delves to the very
bottom of it's directory tree seeking files every time it's executed.
None of the existing playlist generators I found had caching and none
have any way to configure the output or the directories to scan. While
spiff may be simple, not all players react to it the same so having a
few output configuration options makes it nice.

Examples below:
Note the '?reset' parameter purges and rebuilds the cache and playlist
from scratch and I disabled the html output for clarity.

A 57 item playlist with off-domain references
http://www.trbailey.net/tom/xspf.php?reset
Same 57 item playlist cached using MySql    
http://www.trbailey.net/tom/xspf.php
Run the cached url through the validator and see how fast it really is.

The underlying philosophy is this:
To the user, waiting for 10+ seconds while the server reads every single
matching file in a directory tree to find tags is unacceptable.
To the server having to re-read every file for every hit on the playlist
generator is a huge waste of resources. Especially on a busy site
feeding playlists.

Thus XSPFPHP was born.
Looking back I would have chosen a different name but hindsight is
always based on experience one didn't previously have.
:)

-Tom, author of xspfphp.sourceforge.net


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze-3]

 > A 57 item playlist with off-domain references
 > http://www.trbailey.net/tom/xspf.php?reset

2.6 seconds

 > Same 57 item playlist cached using MySql
 > http://www.trbailey.net/tom/xspf.php

avg .7 seconds, and it's probably mostly network access.

Obviously a real-world MP3 collection would go way past 30 seconds...

It's fascinating that this project manages a catalog, which is a natural
complement to XSPF.  Catalog management and XSPF are separate beings
that are joined at the hip.

I know of existing projects that manage a MySQL catalog of local MP3s.
It's the XSPF emphasis which is new.

One direction you could go is to do a content resolver.  A easy way is
probably to to approach this as a resolver plugin for Playdar.  It might
interface a remote collection to the local context.  So there's a user
with a web storage account holding their MP3s, like on MP3tunes or the
early versions of Streampad, and they're on a machine at work which
doesn't belong to them...  Playdar is running on the work machine, your
module is helping that Playdar instance connect to the remote storage
acount...

Another direction is to eliminate the MySQL dependency by using some
kind of built-in db, like CouchDB or a flat file.

Anyhow, it's a groovy thing.  glad to see it...







Tom wrote:

> A basic philosophy and why I began this project.
>
> I'm learning PHP so I was looking for a relatively easy project that
> would allow me the opportunity to learn scripting basics. My son and I
> have had an ongoing competition with embedding players on Myspace and I
> thought it would be neat the use PHP to dynamically generate a playlist.
> Especially if all I had to do to change the page was upload or delete
> music. But after seeing the horrible performance of those I found at
> LacyMorrow, and the two plus year old musicplayer.sourceforge project
> and ohters I decided I could do better. I was going to write my own tag
> reader but I found get_id3(). I was going to write my own flat file
> cache but discovered that get_id3() already has caching. So far, to my
> knowledge, this is the only id3-spiff playlist generator that uses a
> caching mechanism making playlist delivery nearly instantaneous.
>
> My home server and the project home page runs on an old Intel PIII
> 512Meg over 640K DSL and it generates the playlist as fast as the
> browser can display it when it's cached. No other spiff generator can do
> that. The sourceforge version titled: 'php-xspf-gen' delves to the very
> bottom of it's directory tree seeking files every time it's executed.
> None of the existing playlist generators I found had caching and none
> have any way to configure the output or the directories to scan. While
> spiff may be simple, not all players react to it the same so having a
> few output configuration options makes it nice.
>
> Examples below:
> Note the '?reset' parameter purges and rebuilds the cache and playlist
> from scratch and I disabled the html output for clarity.
>
> A 57 item playlist with off-domain references
> http://www.trbailey.net/tom/xspf.php?reset
> Same 57 item playlist cached using MySql    
> http://www.trbailey.net/tom/xspf.php
> Run the cached url through the validator and see how fast it really is.
>
> The underlying philosophy is this:
> To the user, waiting for 10+ seconds while the server reads every single
> matching file in a directory tree to find tags is unacceptable.
> To the server having to re-read every file for every hit on the playlist
> generator is a huge waste of resources. Especially on a busy site
> feeding playlists.
>
> Thus XSPFPHP was born.
> Looking back I would have chosen a different name but hindsight is
> always based on experience one didn't previously have.
> :)
>
> -Tom, author of xspfphp.sourceforge.net
>
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>
>

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze-3]

One other comment -- you could hook your module up with Yahoo Media
Player to eliminate the need for a flash player.

This:

<a href="http://www.trbailey.org/music/xspf.php"
type="application/xspf+xml">my playlist</a>
<script type="text/javascript"
src="http://mediaplayer.yahoo.com/js"></script>

instead of this:
<td><object id="Pink" type="text/html"
data="http://www.trbailey.org/music/player.php" width="620"
height="320"></p>
...
<script type="text/javascript"
src="http://www.trbailey.org/music/player/swfobject.js"></script>
<div id="player">This text will be replaced</div>
<script type="text/javascript">
var so = new
SWFObject('http://www.trbailey.org/music/player/player.swf','mpl','600','300','9');
so.addParam('allowscriptaccess','always');
so.addParam('allowfullscreen','');
so.addParam('bgcolor','#cccccc');
so.addParam('flashvars','&file=http://www.trbailey.org/music/xspf.php&item=8&displayclick=play&frontcolor=#ff9900&lightcolor=#ffffff&screencolor=#000000&controlbar=bottom&playlist=right&playlistsize=400&volume=10&icons=false&logo=http://www.trbailey.net/images/pink.gif&mute=false&quality=true&repeat=list&skin=http://www.trbailey.org/music/player/bekle.swf');
so.write('player');
</script>

Just a different way of slicing it, with different strengths and
weaknesses...


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Thomas R Bailey]

Lucas Gonze wrote:

 > A 57 item playlist with off-domain references
 > http://www.trbailey.net/tom/xspf.php?reset

2.6 seconds

 > Same 57 item playlist cached using MySql
 > http://www.trbailey.net/tom/xspf.php

avg .7 seconds, and it's probably mostly network access.
  

Sorry I didn't respond right away, I had a Microsuck Vista BSOD while writing this and had to move over to XP for a while.

Yea it's almost as fast as as a flat file, which is important when dealing with hosting providers and their terminally slow servers.
Even I get impatient when I see a blank music player.

Obviously a real-world MP3 collection would go way past 30 seconds...

  

But what would you play it with?
This playlister will deliver 500 tunes in one playlist as fast as it can be downloaded, (I hope)
but few players will cope with that many tracks. They aren't really designed for that large a playlist. are they?

Here's an idea. I found an old 70's torrent containing 300 mp3 tracks. I'll download it and see
how JW's player copes with it then post a link here for perusal. It's 94% as I write this. The url will be
http://www.trbailey.net/Super70s/xspf.php
http://www.trbailey.net/Super70s/player.php
These will be working by the time I send this. I'm upgrading my server later this week from a PIII 1GHz 512Meg to a P4 3.4 GHz 2Gig. I'll try to get timings with both and see how much difference there is. I suspect it will be like night and day. The PIII takes about 8 seconds.

It's fascinating that this project manages a catalog, which is a natural 
complement to XSPF.  Catalog management and XSPF are separate beings 
that are joined at the hip.
  

Not sure what you mean by "Catalog".
If you mean it dynamically generates from files, yes. But this is not really a database of music, yet.

I know of existing projects that manage a MySQL catalog of local MP3s. 
It's the XSPF emphasis which is new.

One direction you could go is to do a content resolver.  A easy way is 
probably to to approach this as a resolver plugin for Playdar.  It might 
interface a remote collection to the local context.  So there's a user 
with a web storage account holding their MP3s, like on MP3tunes or the 
early versions of Streampad, and they're on a machine at work which 
doesn't belong to them...  Playdar is running on the work machine, your 
module is helping that Playdar instance connect to the remote storage 
acount...
  

I've heard of Playdar but haven't seen or read about it yet.
Is that the package has xmoov.php?

That's also what I'm thinking in terms of the Gallery3 project. (gallery.sourceforge.net) This work is intended to become part of a
Gallery3 module. However, the G3 developers are someone bland about using their Photo Gallery as a back end file server
for media files so I've gotten a really lukewarm response from them.

There is also a newer model called "RESTful" intended to be used for just what you described above.
It uses an implied query in the url to dynamically generate output like RSS, ATOM, TVRSS, or in this case XSPF.
It has the advantage that is supports writing as well as reading so one could actually upload files using RESTFUL.
With a web front end to upload to a "catalog" one could easily generate a playlist for any contents matching a query.
The YouTube Atom API is a RESTful implementation, whether they call it that or not.

RESTful is the general direction I'm planning at the moment.

Another direction is to eliminate the MySQL dependency by using some 
kind of built-in db, like CouchDB or a flat file.

Anyhow, it's a groovy thing.  glad to see it...
  

It already has flat file caching but it uses a  berkley style db which is slated to disappear soon.
I didn't include instructions to make it work for that reason.

Berkley is a database implementation that's been around since the 60's. Let it Wrest in Piece..es.

Thanks for comments, I appreciate them. Test those links above, it takes about 8 seconds for me but I have a 100mb connection.
And the player seems to do fine with 290 tracks. I guess I'm wrong.
-Tom

Tom wrote:
  

A basic philosophy and why I began this project.

I'm learning PHP so I was looking for a relatively easy project that 
would allow me the opportunity to learn scripting basics. My son and I 
have had an ongoing competition with embedding players on Myspace and I 
thought it would be neat the use PHP to dynamically generate a playlist. 
Especially if all I had to do to change the page was upload or delete 
music. But after seeing the horrible performance of those I found at 
LacyMorrow, and the two plus year old musicplayer.sourceforge project 
and ohters I decided I could do better. I was going to write my own tag 
reader but I found get_id3(). I was going to write my own flat file 
cache but discovered that get_id3() already has caching. So far, to my 
knowledge, this is the only id3-spiff playlist generator that uses a 
caching mechanism making playlist delivery nearly instantaneous.

My home server and the project home page runs on an old Intel PIII 
512Meg over 640K DSL and it generates the playlist as fast as the 
browser can display it when it's cached. No other spiff generator can do 
that. The sourceforge version titled: 'php-xspf-gen' delves to the very 
bottom of it's directory tree seeking files every time it's executed. 
None of the existing playlist generators I found had caching and none 
have any way to configure the output or the directories to scan. While 
spiff may be simple, not all players react to it the same so having a 
few output configuration options makes it nice.

Examples below:
Note the '?reset' parameter purges and rebuilds the cache and playlist 
from scratch and I disabled the html output for clarity.

A 57 item playlist with off-domain references 
http://www.trbailey.net/tom/xspf.php?reset
Same 57 item playlist cached using MySql     
http://www.trbailey.net/tom/xspf.php
Run the cached url through the validator and see how fast it really is.

The underlying philosophy is this:
To the user, waiting for 10+ seconds while the server reads every single 
matching file in a directory tree to find tags is unacceptable.
To the server having to re-read every file for every hit on the playlist 
generator is a huge waste of resources. Especially on a busy site 
feeding playlists.

Thus XSPFPHP was born.
Looking back I would have chosen a different name but hindsight is 
always based on experience one didn't previously have.
:)

-Tom, author of xspfphp.sourceforge.net


    

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Thomas R Bailey]

Lucas Gonze wrote:

> One other comment -- you could hook your module up with Yahoo Media
> Player to eliminate the need for a flash player.
>
> This:
>
> <a href="http://www.trbailey.org/music/xspf.php"
> type="application/xspf+xml">my playlist</a>
> <script type="text/javascript"
> src="http://mediaplayer.yahoo.com/js"></script>
>
>  

Interesting but it doesn't seem to work with an existing playlist.
??

Per large playlists, I'm surprised, my PIII server delivers 240 playlist
items in 4 seconds or so.
http://www.trbailey.net/Super70s/player.php
I'm working on getting the flat file cache to work but it requires extra
php modules.
-Tom


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist