Data In / Data Out - Part 1

One of the major requirements of the Open Media System was the solutions needed to be playback server agnostic. Before we can start putting data into different playback servers we need to know what's already there, so we started with getting the data out of the different servers. To do this we recreate the existing database of playback events as Airings using the Broadcast Synchronization module. Regardless of what type of playback server or the amount of time you are scheduling through Drupal, the Airings look the same. This standardization of Airings allows us to treat both scheduling and and the display work the same regardless of the playback server.

At this point in the project we've been able to populate Airings from the playback event databases on Princetons, NEXUS (NEXI?), and Synergies using an RSS feed that is updated every time cron runs.

The Princetons already had an RSS feed, but the formatting wasn't quite what we needed. Televue was nice enough to add a guid (globally unique identifier) to the feed, but they added it as an custom feed element called psg:eventId. Anyone who has upgraded to the Princeton 3.5 release, now has psg:eventId in their feed. The problem with Princeton is that they still use the filename as the unique identifier. This is a problem because when Feed API sees a guid again in the feed, it assumes that is an update to the original not another airing of the same video. This is how RSS was designed to work. If the name globally unique identifier doesn't convey how that element is supposed to be used, I'm not sure what else I can do to make this clear. Because Princeton added psg:eventId, but didn't change the guid we have to change that before Feed API sees it.

The original Princeton RSS...

Our modified feed...

Leightronix was nice enough to add a feed for us. All Leightronix customers who have updated to the latest firmware now have the option of using RSS. The Leightronix feed looks like this...

Not exactly the same, but it has enough elements we can start to map the fields to the Airings content type created by the Broadcast Synchronization module using Feed Element Mapper.

channelAutin uses a Synergy playback server. Synergy wasn't as supportive of the project as Leightronix, but because they have fewer restrictions on what you can do with your server, Rich Vázquez wrote an RSS interface for Synergy in Ruby on Rails. Because we had complete control over who that looked, the Austin's feed from the Synergy is really the ideal version of feed...

The Synergy fed is currently missing a link element. The feed contains the min amount of information to block out the time so the Timeslot Scheduler module doesn't try to schedule something on top of shows that are already there. The link elements in the other feeds are the video name itself. That is unique in each playback system at each station, but most likely not unique between stations. This is an issue that has been brought up several times and one we are still trying to come up with a solution. One idea we've been talking about with Robert Nichols from PEGMEdia.org is generating a bittorrent seed for every file and using that as the unique id regardless of whether the files is being shared as a torrent or not. If we do end up using torrents to share content, we should also give serious consideration to following the naming convention used by torrent trackers for television shows...

TITLE-s01e01-CODECINFO

Currently we are no enforcing unique file names even at DOM. While files with the same name can be encoded and added to the archive because they are put in directories based on the project name, if multiple users add files called episde1.mpg this will cause a problem when files with the same name are moved from the archive to the playback server.

So as we move to moving video files and scheduling information, should we add Season to required fields for the Show module and start changing the file names to match that format?