2/1/10 UPDATE: I've posted an in progress copy of the module below. I've added caching and the module's providing a recently played block. I was having trouble with not being able to authenticate from yohnson's Shoutcast module, so this module's still pulling tracks from the played.html page. I'm working on providing an extended recently played page and the Amazon API integration.
Three years after first saying I was going to do it, I've finally started on a Now Playing module. Initially, I'm focusing on storing a complete history of tracks played and displaying recently those played. Once the module's stable, I may try leveraging the track history data by creating a charts module, but we'll see.
I have a few questions about approaches to data storage and integration with the rest of station's modules. First, a bit about what station_nowplaying does, so far, and what I plan to have it do:
1) Pull song history (song, artist, album, label, date/time played) from a Shoutcast stream's Song History page (ex. http://energy14.egihosting.com:6222/played.html). Dates and times will be adjusted to handle cases where the Shoutcast server is in a different TZ from the Drupal server.
2) Store songs in a history table and either link to an existing, or enter a new album entry into the station_catalog table. I'll provide the means to filter out certain track titles, like promos, ads, etc. based on track title.
3) Provide a recently played list block and extended recently played page node. Played date/time will be TZ adjusted.
4) Integrate with the Amazon module to provide an affiliate "Buy" link in blocks and pages.
Step #1 is almost done, working well, and I'm ready to store data. I've added a table, station_nowplaying, to store played history and link track history to a station_catalog item. I'm on the fence about where song titles should be stored. I was considering creating station_playlist 'Master Playlist' and storing tracks in station_playlist_track. I've reconsidered and now think a separate station_nowplaying_tracks table that links to station_nowplaying and station_catalog records makes more sense.
I'd really appreciate feedback on storage approaches and relationships. I've also attached the station_nowplaying admin settings as they stand now.
| Attachment | Size |
|---|---|
| nowplaying.tar_.gz_.txt | 4.94 KB |
Comments
Drewish, any thoughts on
Drewish, any thoughts on track storage here?
Station: Current Program
Drewish, the block is called Station: Current Program, and it just lists the show host. Is that the same block as nowplaying ?
Is this unique to Shoutcast?
Most of the "Now Playing" solutions I've found on the Web are unique to Shoutcast, Icecast or WinAmp. I'm wondering if there is a way to extend the usability of this one to include other radio automation systems like those used in commercial stations (Google/Wide Orbit, iMedia or Prophet, for example).
Not unique...
It is not unique but Shoutcast and icecast are the mosted used streaming systems. If you are trying to interface to a Broadcast Automation system that can output a html page of the last songs played then I think that the parsing of the different formats of html pages could be setup to be configurable.
However if your automation only puts out this info to a UDP port then you can use netcat (Linux command line program) to listen to the UDP stream and write it to a file that the information can be pulled from. If it only put this info out to a serial port then you will need to figure out how to redirect that stream to a file that can be read. If you need examples of how to do this let me know.
I am not sure the pull method is the best method, as the automation system knows when the info has changed. A push method that updates the info when it changes would be better in my mind. Right now the now playing block does not update unless the page is reloaded so it is pointless to have a system that works that way to keep the info up to date quicker.
Polling "Now Playing" Data
I don't recall exactly how we set up our Google Automation system to do this, but I do know it writes a node of XML each time the stack changes for a given media type (in our case, it was "Teaching Program" and "Music" -- commercials, liners and promos were not written to the stream.
YES.com, a content aggregator polled a port on our streaming computer to pick up this XML file whenever it changed. Here's where my understanding breaks down on whether it was PUSH or PULL. I can't imagine Yes.com staying afloat very long if they had to listen to thousands of stations and update their data whenever it changed... but then again, they're an odd operation.
WHAT I PROPOSE:
Identify how all of the MAJOR automation systems send this data and trigger events (like saving the XML file in Google Radio Automation). I'm sure ShoutCast and similar programs have a way of picking up the Now Playing XML from an automation system. That way, nothing needs to be changed in the Drupal modules themselves.
Station log with pulling SHOUTcast track history
I'm now taking a different approach and have decided to create a station_log module to collect and store track info from stream metadata. This module will only log track data, albums to the station_catalog and track info to a station_log and station_log_track table. I think that the display of the data should be handled by station_schedule. The station_log and log_track data could then be used for Recently Played blocks, extended playlist page display, and charting. I agree that the recently played block should refresh itself via AJAX.
I'm working with yohnson on updates to the Drupal SHOUTcast module to pull track history from the server's XML data. So, I'm focusing on pulling the data to meet my station's needs. I'm more comfortable with pulling track history every 5 to 10 minutes and caching it. After each pull the latest track list will be compared against the cached list to get the differences for the log.
hi
I am interseted in that scrip to for my internetradio station. It has to read out my shoutcast stream if it is possible
Goos Mante