Posted by mattrock on April 26, 2007 at 8:04pm
I am seeking to corral thoughts on playlist entry. A recent discussion with Drewish yielded some thoughts on a method of tracking "played songs." There was a consensus that expansion or re-building of the current playlist entry module in station is in order. I feel it is fitting to discuss this in conjunction with the discussion of "Now Playing."
Goals:
- Present Currently Playing Song on site
- Define actions of presentation for non-music shows; I.E. what information is presented for a talk show?
- Provide archival access to historical playlists, searching by time, show, station, song, artist, etc...
- Define handling mechanism for no-shows or overflows beyond pre-scheduled times so that played song stays attached to the respective host who played the selection.
In addition to these common goals, I have also laid out our needs @ WSUM in prior posts [Playlist Entry & Live Playlists]. The highlights of what we are looking for include;
- Parse the "Current Play" to Icecast2
- Pull "Current Play" from automation when no host is present
- Form views to assist with CBI Charts
- Optional MusicBrainz lookup for conformity of the entries and additional reference to played item
- Inclusion of connected stream listener count for Sound Exchange reporting
I am in the process of collecting various scripts to include here. Please feel free to add any comments, requests, suggestions, etc.
Comments
Thanks, here are more thoughts to corral :-)
Thanks for posting this. In addition (or extension) here are more goals...
I'd prefer to pull data from station automation software log files daily than from stream meta data in real time. I believe that a log file method will be more reliable for archival purposes, and would make this module more appealing to terrestrial-only stations. The software the station I'm developing for generates a daily CSV log file and I imagine most other packages do too. I've already written code that parses most delimited and Excel data files (auto-detects type based on file extension and file contents). The source of the data shouldn't matter, having multiple options would make this module more appealing.
Not sure how these ideas would impact the current station.module db schema. I started looking at the schema and thought that two new tables would be required.
station_track
- nid
- title
- catalog.nid (map tracks to albums)
station_log
- timestamp
- track.nid
Then I'd add a 'date_added' field to the station_catalog table to enable the 'What's New' feature.
If the log archive is handled daily, rather than in real time, the now playing list would need a separate data storage mechanism. I'm happy with simply saving the data in a file or directly in a node or block. I haven't thought through the performance implications of this yet.
I should also say that I think the current playlist entry manual entry method should be retained. We have a few programs that are recorded as a single track and I need to give the DJ the ability to manually enter program tracks.
I'm sure I'll think of other stuff, but this is the major stuff I need to accomplish soon. After these features are developed I'll want to create a "Buy now" feature tied to affiliate-related modules.