Data In / Data Out - Part 1

kreynen's picture

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...

A Journey through Aesthetic Realms Episode 247 - Wed, 06 May 2009 00:00:00 -0600
<pubDate>Wed, 06 May 2009 00:00:00 -0600</pubDate>
A Journey Through Aesthetic Realms: An award-winning series that presents entertainment programs with lively performances from around the world.  This long-running television program had been regularly broadcast in the United States to 90 million viewers.
<category>Well-Being & Lifestyle</category>

Our modified feed...

<title>A Journey through Aesthetic Realms Episode 247</title>
<pubDate>Wed, 06 May 2009 00:00:00 -0600</pubDate>
<startDate>Wed, 06 May 2009 00:00:00 -0600</startDate>
<endDate>Wed, 6 May 2009 00:28:31 -0600</endDate>
<description>A Journey Through Aesthetic Realms: An award-winning series that presents entertainment programs with lively performances from around the world.  This long-running television program had been regularly broadcast in the United States to 90 million viewers.</description>
<guid isPermaLink='false'>96381</guid>

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...

<pubDate>Wed, 06 May 2009 00:00:12 -0600</pubDate>
<startDate>Wed, 06 May 2009 00:00:12 -0600</startDate>
<endDate>Wed, 06 May 2009 01:48:01 -0600</endDate>
<description>Urbana City Council 4-13</description>
<guid isPermaLink='false'>1241099569</guid>
<category>Category Undefined</category>

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...

      <title>Orientation Promo</title>
      <description>Orientation Promo</description>
      <pubDate>2009/05/05 00:28:30</pubDate>

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 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...


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?


Regarding the Season question

stefanwray's picture

At channelAustin we have 3 seasons that are 4 months long:

Spring - Feb 1 to May 31
Summer - June 1 to Sept 30
Fall - Oct 1 to Jan 31

Producers can sign up for a Series for the duration of the Season. And each Series has a number of unique episodes, with a maximum of 16 in the 4 month Season.

We could have fields on Create Show that generate this:

Series Title

One problem with this might be that there is no standard for Season. This may only be an issue for sharing among other stations.

If that is not a concern, then it can be useful to have both a Season and Series field added.

Season isn't intended to be

kreynen's picture

Season isn't intended to be the time of year, but a run of the show for series shows. This makes less sense in public access than in commercial broadcast where a specific number of episodes are purchased for that "season". Season is more or less the years the shows been running, but because of writer strikes, Olympics, etc the seasons start and end at different times of the year.

stefanwray's picture

RSS interface for Synergy in Ruby on Rails

The link to this has changed to:

RSS interface for Synergy

cacimar's picture

I'll do some updates tonight. The long term goal is to get this reading and writing from synergy for now and eventually port it to a more windows friendly language (VB,C# or something that runs as a service as opposed to a web application).

I'll increase the documentation over the next few days as well.