XML Minimum Poll Period

[wbarthol]

I'm writing a little tray application that polls the index.xml and shows a notification balloon when the song changes. How quickly are "we allowed" to poll the index.xml file? Is there a recommended minimum?

[grexican]

mosey has code that knows how long the current song is going to be playing for (estimated, pretty accurately).  I'd talk to him before I start polling.

I also have this in the works, as a part of a whole application -- integrated wazee chat, message board, song notification, favorite song/artist notification, rating system, etc.  I just haven't had time to finish it up and release it.  What can I say, senior design is a bitch

[wbarthol]

Would it be hard to have the start time and song length added to the XML? That would eliminate the need for polling at all...

[TwisterX]

there's an IRC bot that spams this:

(15:02:55) • radiowazee Now playing: Cake - I Will Survive (3:54)
(15:06:47) • radiowazee Now playing: [radio.wazee] - Dr.Dyno -- LIVE Friday's @ 7PM (0:16)
(15:06:58) • radiowazee Now playing: Alston - 2 & 10 Low [dl@wazee] (3:49)

so this thing receives times, maybe u can do somethign with that?

[wbarthol]

I'm pretty sure the IRC bot retrieves the details from the media player you are using. What I've done so far is:

1. When program loads it grabs the XML
2. Every 5 seconds it then calls the page with the HTTP header If-Modified-Since so that Wazee's server will only return the page if the XML has changed, this will keep the load down on the server
3. If the song has changed it then backs off for 3 minutes (I'm assuming most songs will be longer than 3 minutes), after which it goes back to step 2.


Does this sound reasonable? I think it should result in hardly any load on the server.

[mosey]

Would it be hard to have the start time and song length added to the XML? That would eliminate the need for polling at all...

Don't poll the XML file. It would be inefficient and could never work as accurately as the following system that is already in place.

It's not XML, but it's pretty easy to parse out:
http://www.wazee.org/bg_transport/currSong.php

Sorry, I haven't jumped on the XML bandwagon yet, as most browsers don't have any real parsing implementation built into their javascript parsers yet. That url is the one your browser calls once per song to change the currently playing info at the top of all pages here on the site. Format is name=value;name2=value2; with the values being encoded for use in URL's.
Some values you'll be interested in:
song: the song title

artist: yeah

nextPacket: number of seconds until new data SHOULD be available. This is occasionally wrong, you should check the msid value to see if you actually received different data, and if not retry again after about 4 seconds.

displayTime: exactly when the song transition is estimated to occur. nextPacket will reach 0 about 24 seconds before the song actually changes on the stream, allowing any clients that are going to connect about 24 seconds to do it and still update on time. This way, the server does not get hammered with 100 requests for currSong.php at exactly the same time. Thus, when displayTime is > 0, you should wait this number of seconds before showing the popup, if you want it to come up exactly when the song transitions. (When displayTime <= 0 the song currently described in currSong.php has already been playing for -displayTime seconds.)

flexibility: recommended variation from nextPacket to make a new connection. If you anticipate many users of your application, please have your applications access this file every nextPacket + (a random decimal between 0 and 1 * flexibility) seconds.

Everything described above is implemented in javascript at http://www.wazee.org/wazee.js in function handleSongPacket, in case that helps you to see what you should do.

Have fun  

[wbarthol]

That is perfect... Thanks heaps mosey.