Lessons Learned During the Davis Implementation

kreynen's picture

Overall the Davis implementation went well and they are on their way to making http://dctv.davismedia.org/ a feature complete install that gives their members more functionality and control.

One thing we've realized is that we still have a ways to go before the Open Media System can be downloaded and installed and configured by anyone else. While we've started rolling content type creation, the associated functions, views, and theming into modules, working in Davis it was very clear we haven't been doing a great job keeping those modules updated in CVS. Darrick had done everything he could as far as downloading and configuring what was available before be got to Davis, but in many cases the minor changes we had made here and there hadn't been committed to CVS. In some cases, like TVframe, there were still big problems in the version in CVS. Other issues were modules that had dependencies that we'd forgotten to add or specific configuration that we should either set or warn when it isn't set. One example om_show requires Filefield Local's weight be set to 99 (or some other really "heavy" weight). We've been using the Utility module to set this through the UI, but we're going to add this to Filefield Local's install and add a warning to om_support.

Most of the errors we ran into in Davis we'd already solved at least once. It just took us a while to remember and would likely be a show stopper for other locations. We have lots of notes we'll be converting to todo lists and trying to bang out over the next 2 weeks so implementations in Boston and Amherst require less tweaking.

Multisite
We did encounter a new batch of errors that arose form the fact that Davis is using a multisite configuration. There had been an error logged against MERCI some time ago about this, but because we rarely work in multisite environments we were never able to accurately debug the error. The biggest problem has been in modules that add table names as variables to their query. The solution was relatively simple. When using db_query, table names must be bracketed so that Drupal can add the prefix for a multisite install. When Drupal sees {merci_reservation_detail} in a multisite configuration it knows that {merci_reservation_detail} really means dctv_merci_reservation_detail. When using variables for that table names, the structure needs to be include an extra step. We've updated queries that looked like this...

$reservations = db_query("SELECT ctn.nid, ctn.title FROM {$table} ct INNER JOIN {merci_reservation_detail} md ON ct.vid = md.vid INNER JOIN {node} ctn ON ct.vid = ctn.vid WHERE md.item_nid = %d AND $column_end_date >= '%s' AND NOT (md.item_status <= %d)", $node->nid, $time, MERCI_ITEM_STATUS_AVAILABLE);

To this...

$reservations = db_query("SELECT ctn.nid, ctn.title FROM {".$table."} ct INNER JOIN {merci_reservation_detail} md ON ct.vid = md.vid INNER JOIN {node} ctn ON ct.vid = ctn.vid WHERE md.item_nid = %d AND $column_end_date >= '%s' AND NOT (md.item_status <= %d)", $node->nid, $time, MERCI_ITEM_STATUS_AVAILABLE);

This forces Drupal to process the value to $table before db_query so everything is multisite friendly. That change to MERCI has already been committed.

Again, our goal is to get all of these fixes committed back to CVS this week to make the upcoming so that the implementations in Boston and Amherst come straight from CVS.

Here are just a few of the changes we are planning on making...

om_support install checklist and stats

Checklist - We are still moving functions out of om_support into the modules that are more appropriate, but we're also going to add some new functionality to om_support to help with implementations. We try to keep the enforced modules dependencies to a minimum, but we end up building on themes that require other modules to be installed. This aren't really requirements, but more of a "it would be a lot better if you did" modules (yes, that is a Wooderson reference). We're going to borrow from the way the SEO Checklist works. This function won't require you to install anything or prevent you from installing modules other than what we recommend, but will show us everything we normally install as part of an installation.

Archive and FFMPEG Status - This is something that we've desperately needed at DOM and will help other places as well. We've lost read and/or write access to the mount point to our RAID several times for a variety of reasons. om_support will now have the option of emailing someone if the connection to the directory specified in File Field Local or Media Mover aren't available. Our current approach of waiting until someone tries to add a Show and it doesn't work is not good.

Stats - The stats page on Denver Open Media's site will be rolled into om_support as both a page and a block can be made public or kept private.

om_handbook using Book vs. taking over Book

In previous installs we've added a structure of Book pages that make up the Open Media Handbooks. This limits what can be done with Books in Views and permissions. In Davis, we started using a new content type called om_handbook_page to populate books. That content type is now created when om_support is installed along with om_handbook_alerts. om handbook_alerts is populated by FeedAPI (added a requirement of om_support!). This allows stations to see any new pages that have been added on www.openmediaproject.org/handbooks, but won't necessarily create the om_handbook_page automatically. The reason for this is that FeedAPI caches the items it downloads form an RSS feed. When we are setting up new sites, we want all the documentation available. But after a site invests time in customizing that documentation, we wouldn't want the content overwritten if FeedAPI was updated or reinstalled and it's cache was reset. Instead om_support will include an option to automatically create new handbook pages when checked, but will require a user to determine what to do with om_handbook_alerts when not check.

This will really streamline the process of configuring documentation at each location. For the sites we've already implemented, I will convert you book pages to om_handbook pages when I update om_support.

Adding Preshow content type

om_preshow is almost a duplicate of Show content type, but doesn't use file_field for video. Instead, om_preshow has an optional field for the anticipated filename. We came up with solution to solve Davis's goal of getting their archive of metadata for VHS, beta, and DVD content online and eventually adding video to it. Adding these as shows would have caused some real issues with scheduling. If the autoscheduling process grabbed even 100 of highest rated shows in a category and then tried to schedule them, it's entirely possible none of those shows would have MPEG2s available. Adding the JOIN to the files table from the Voting tables and/or the Timeslot Theme tables is certainly possible, but it's much easier to working with a large group of shows with valid MPEG2 than to try to find shows with valid MPEG2 in a large group of exceptions.

Preshows will also be useful for subscribing to content from other stations. We won't be working on this until after July, but since it is much easier to move metadata about shows than the shows themselves this allows much more flexibility than directly populating Shows. A site with limited bandwidth might want to review shows before initiating the downloads. Using FeedAPI to populate Preshows that are only converted to Shows when the expected video is detected in a specific location,

Archive Checkbox

A simple change to content type. Darrick came up with this so we'd have the potential of removing the archive MPEG2 from the local RAID when the file was successfully uploaded to Archive.org and the file has not been scheduled to air in 12 months. The flash file would still be available locally. If the show was scheduled, the broadcast quality version would need to be downloaded again.

Locally Produced Checkbox

Another simple change to content type. This was something we were surprised has never come up before. We've always included geotagging on Projects and Shows, but we always intended that to be used for the places the content is about which is not always were the content is produced. We're sure the use of this checkbox will vary from station to station, but it will allow stations to report on the amount of content they are airing that is locally produced. This will be more important as we enable content to be more easily moved between locations.

Both the Archive and Locally Produced Checkboxes will be included in an update to om_show and om_project for stations we've already implemented.

I'll post more notes as I have, but I'm hoping John and Darrick can contribute to this as well.

Login to post comments

Another issue we keep

kreynen's picture
kreynen - Wed, 2009-06-03 18:35

Another issue we keep running into is duplicate URL aliases generated by pathauto. This happens a lot with om_broadcast_sync if the om_airings populated by FeedAPI are set to use [title-raw]. Instead, airings should be set to airing/[nid] so you don't get errors like...

# user warning: Duplicate entry 'airing/harry-potter-and-dark-lord-waldemart-2-0/feed-' for key 2 query: INSERT INTO url_alias (src, dst, language) VALUES ('node/20756/feed', 'airing/harry-potter-and-dark-lord-waldemart-2-0/feed', '') in /usr/www/dom/modules/path/path.module on line 112.
# user warning: Duplicate entry 'airing/bodycam-0/feed-' for key 2 query: INSERT INTO url_alias (src, dst, language) VALUES ('node/20851/feed', 'airing/bodycam-0/feed', '') in /usr/www/dom/modules/path/path.module on line 112.
# user warning: Duplicate entry 'airing/beyond-broadcast3-0/feed-' for key 2 query: INSERT INTO url_alias (src, dst, language) VALUES ('node/20890/feed', 'airing/beyond-broadcast3-0/feed', '') in /usr/www/dom/modules/path/path.module on line 112.

In addition to the patterns getting set, the feed options should be turned off. These are things we can check with om_support's new checklist, but I'm hoping the module install can set that automatically instead. If anyone has some time to research that, I'd really appreciate it!

AttachmentSize
pathauto_pattern.png 23.67 KB
pathauto_feed.png 27.07 KB

a second on the locally produced checkbox

jdaniels@drupal.org's picture
jdaniels@drupal.org - Fri, 2009-06-05 02:20

Would or could the locally produced checkbox be searchable? Could I look for videos produced within 25 miles of my center? Might find that useful for aggregating work from communities within a certain radius or region.


I saw your question on the

kreynen's picture
kreynen - Fri, 2009-06-05 02:47

I saw your question on the ACM East video on blip.tv. We are geotagging all shows, but that is really for the area the show is about. The locally produced solves a problem of a Denver producer who creates a documentary about Moab or the NY producers who create a short during the DNC that we download from PEGMedia.org. The Moab video can be reported as locally produced, but the DNC video (even though the geotag would be within 25 miles of Denver) wouldn't.