Expanding on Stefan's post Telvue Playback Server and Cloudcast Integration With Drupal, let's document the ideal workflow related to how VOD files/media will be created/stored/displayed. This discussion is primarily for stations using Cloudcast/Telvue because I am referencing the uuid, but the workflow could really be applied to any other system as well where a media link is getting mapped through Drupal's media module.
First, let's assume that uuid is incorporated into the system as described in Stefan's post (http://groups.drupal.org/node/299933).
Workflow Part 1
uuid field is exported via cloudcast and imported via feeds using the node processor and creating content in type cm_show. In addition to uuid, the feed importer maps other fields that are shared between Cloudcast and shows, such as Episode, description, etc.
Workflow Part 2
The second part of the workflow has a few potential options:
Option A: cm_show has no media field. Instead, we directly create video file entities for the media. uuid would also be stored with a video entity that is created. A separate feed importer has to be set up for this. This second feed importer uses file processor (with Feeds: Media Internet Files and mapping to video file type) to map the URL to URI. We then use Views with a uuid relationship to display the media wherever desired (on a show, on a project, etc).
Option B: A media field is added to cm_show. We then map the media through this field, use one feed importer, and media is by default available wherever show data is available, and can be managed through the content type display along with other fields.
Option C: We have a totally separate content type for the media, which references a show through an entity reference field. This is the old workflow and so far as I am aware we are moving to deprecate this because Option A replaces this.
Below is an image demonstrating Options A and B for those who prefer visual diagrams (click the attachment at the bottom of the post to see the original, full size image). Neither workflow seems wrong, but there are pros and cons for both. The Cons with A include that it makes the process a little more complicated and thus harder for beginner/intermediate drupal admins to set up. The Cons with B include that in the case of adding media directly at admin/content/file you would then have to go to the applicable show and use the media browser to attach.
My understanding is that quite a few stations, including ChannelAustin and MNN, will be adopting Option A. Is this correct?
Just want to make sure these options are accurate and open it up for discussion. The more stations that share this same workflow, the easier it is to share exports for feed importers, bug fixing, etc.
| Attachment | Size |
|---|---|
| Video-entity-workflow.001.jpg | 174.23 KB |
Comments
Neither of these workflows
Neither of these workflows are accurate for any station I know of using the Telvue module and Cloudcast modules. MNN creates their schedule in Drupal using https://drupal.org/project/cm_airing_grid. They don't use any Telvue products so this doesn't apply to them at all. Even when stations are pulling in the Airing entities and media entities using Feeds, their workflow starts with a producer or staff member adding the Show node to Drupal. channelAustin's workflow was posted when we started working on the D7 version of the Telvue integration last year.
What you are describing works fine if the goal is to create a display of what staff are adding to Telvue products and may even work with Telvue's Connect product, but we've found that the more staff time is saved when the paper show submission forms are moved to Drupal and producers fill that out themselves. Staff can either review those submissions or push them to the Telvue on node save.
We ARE using a file entity field on Show. We're just not creating the media that way because 1) the Show node already exists and 2) we want more metadata on the media entity so we can find videos using the media browser. The change is to eliminate the cm_show_vod node that was being related to Show using entity reference.
Can we look at these two VOD
Can we look at these two VOD workflow options as a "close-up" of what takes place between steps 6 and 7 in Channel Austin's documented workflow? In other words, is the question more of "what is the most effective way of getting from 6 to 7?" If we currently do not have a standardized approach, this post presents 2 options for the group to consider and weigh in on.
Agreed that this does not pertain to MNN or any CMC not currently using Telvue workflows.
I think there was a
I think there was a misunderstanding on where these workflows are starting. As I stated, I wanted to look at the "ideal workflow related to how VOD files/media will be created/stored/displayed." Thus, we were looking at what happens just when the media file is ready to come in to Drupal. Both of those workflows would assume a previous phase - either show gets started in Drupal, pushed to Telvue, pushed to Cloudcast, and then out the MRSS feed (and then media creation). Or for smaller stations, show gets started in Telvue, pushed to Cloudcast, out the MRSS feed (and then media entity creation). Sorry if this wasn't obvious - my diagrams show a workflow using feeds, this may have been confusing for people not using feeds. The key piece of discussion is the media entity.
So getting back to the specifics on the media entity and this part of the workflow pertaining to where the media entity lives in relation to a show, I think we have clarification:
Great, this is actually what Option B describes and is the key piece. Whether or not feeds is used or a media file is manually created is up to the user, so your answer suggests B is the appropriate setup for where the file entity attaches.
It would be helpful would be to get a list of metadata fields that you are moving to the media entity and fields that you are leaving on cm_show. I am curious on this - is this only custom fields created by each station or is there a development plan to leverage this as part of a feature/module.
This does confirm that Option C is/will be deprecated.
I know... TL;DR, but this the
I know... TL;DR, but this the type of response you will get when keep asking what is essentially the same question for several months. The bottom lines are...
There's no misunderstanding on my part. The move away from using the cm_show_vod content type has been on that project page for more the 6+ months, I discussed it with @emilyf when she asked about it in February, and again when she made the request to add category support to the Feeds: Media RSS module in April...
[2/21/13 11:31:22 AM] Emily E Frazier: hey - trying to see if i can use media cloudcast module to build off some additional functionality. my question is what media display option do i have to use to get it to display off the theme tpl that creates the iframe?[2/21/13 11:31:31 AM] Emily E Frazier: everything looks good except that it won't do the iframe display
[2/21/13 11:32:46 AM] Emily E Frazier: nevermind
[2/21/13 11:32:47 AM] Emily E Frazier: got it
[2/21/13 11:35:13 AM] Kevin Reynen: glad I could help :)
[2/21/13 11:40:51 AM] Emily E Frazier: do you want to make me a co-maintainer on that so i can commit etc?
[2/21/13 11:40:56 AM] Emily E Frazier: i am going to be building off this
[2/21/13 11:40:59 AM] Emily E Frazier: i can also create a new branch
[2/21/13 11:42:37 AM] Kevin Reynen: you've been added
[2/21/13 11:42:47 AM] Emily E Frazier: sweet thanks - what's your preference on that?
[2/21/13 11:42:56 AM] Kevin Reynen: Can you ping Aric about that...
[2/21/13 11:43:04 AM] Kevin Reynen: it's really his call
[2/21/13 11:43:19 AM] Emily E Frazier: ok is he actually doing the dev work on this or are you?
[2/21/13 11:43:54 AM] Kevin Reynen: he is playing the role of co-maintainer/product owner for all the Tevlue related code
[2/21/13 11:44:26 AM] Kevin Reynen: he determines which features get added and when releases are cut
[2/21/13 11:52:07 AM] Emily E Frazier: one more q for you -- is access vision custom coded by you to be working appropriately with feeds?
[2/21/13 11:52:24 AM] Emily E Frazier: aric says he hasn't gotten the feeds integration working and i just don't want to repeat work
[2/21/13 11:53:49 AM] Kevin Reynen: The old way of mapping vod field to cm_show_vod works with http://drupal.org/project/cm_vod_feed... http://drupal.org/node/1556246
[2/21/13 11:54:32 AM] Kevin Reynen: I was hoping to move to http://drupal.org/project/feeds_files, but it didn't work the last time I tried to
[2/21/13 11:54:48 AM] Kevin Reynen: map the VOD feeds directly to the Media entity
[2/21/13 11:54:57 AM] Emily E Frazier: ok
[2/21/13 11:55:04 AM] Emily E Frazier: thanks
While it may look like I'm driving these changes to the way VOD is handled, I am not. I'm simply reacting to the changes happening at the contrib layer with Feeds, Media, Views and Organic Groups and adjusting how I build sites based on that. The fact that so much information about how the existing sites built on the starter kit have been configured is the MAIN reason we can even have this conversation. We certainly couldn't have this conversation about the way RETN's D6 site worked since so much of it is custom.
Importing Show nodes vs. pushing Shows to the Telvue are very different workflows. Saying that you are only concerned with "idealizing" one step in a process where so much differs (different number of steps, different hardware, and different staff comfort levels with self service) at every station doesn't make much sense. Importing Shows from a Telvue doesn't require the Telvue module or even a multistep process. Any station can already create nodes for their an entire Telvue library using http://www.telvue.com/support/product-documentation/princeton-server-api.... I haven't checked the CSV lately, but that should include the Cloudcast URL now that Cloudcast pushes that back to the Telvue. You could literally have a site with thousands of nodes and VOD in < 1 hour without any custom code. John Hauser has been doing a variation on this at AccessHumbodlt for years.
Of course, a CSV workflow doesn't work for stations using multiple playback servers, a Telvue archive server, multiple VOD providers, Cablecast, etc, etc... It has a very limited use, but is the fastest way to get content from a Telvue displayed.
The goal of the cm_ modules, starter kits, and CMDrupal community is very different. It is NOT to find a single site configuration that every client must use, but to share a core codebase that allows stations with different needs and prioritizes to build sites that meet their needs.
The fields on show, project, and media were intentionally unpopulated. Dictating the fields stations had to use was how this was configured in MNN's original Access Center and the Open Media Project. It didn't work. The Community Media Checklist was developed and the documentation improved to lead station staff through that process.
Someone would have to work very hard to convince me that the checklist/ladder approach is not working better than giving users modules that create content types with pre-defined fields.
It's true that the telvue_show_fields module adds the minimum number of fields needed to make Telvue Push work out of the box, but stations can add as many fields as they want to any of these content types and/or use the core Telvue module by writing their own custom push function. I would love to see more stations contributing to https://drupal.org/project/cm_examples and build out a demo area on cmdrupal.org so that would allow new stations to look at the different project, show, etc. forms along with a description of that station's current workflow. I have access to a number of these from sites I've worked on. Most of the original open media beta stations share access to their backend with other station staff, but that doesn't really scale. @sonia was going to try to do that for Project, but it was too complicated and time consuming for her at the time. Taking on that task would be a great way for RETN to get a better understanding of the different moderate and difficult workflows before trying to participate in conversations with channelAustin and MNN at the difficult level.
Using modules like Field Groups, Conditional Fields, Views, Views Bulk Operations and Rules station staff can build increasingly complex workflows themselves with only site builder level skills. There is nothing in any of the cm_ , media_ , or telvue_ modules that would prevent creating a feed driven workflow like you are describing, but there is nothing that will configure that for you either.
I'm not interested in putting a lot of effort into trying to develop or document single "ideal workflows" for any part of CMDrupal, but would love to see more diagrams of existing workflows or workflows that stations would like to implement.
My ideal workflow for getting VOD feeds implemented on a site looks something like this...
The reason this is my ideal workflow is that it isn't trying to get the code to do something more complicated out of the box for someone who doesn't understand it, but it's a workflow where station staff are learning to do increasingly complex tasks themselves. It takes longer and there is work that is re-done, but even if it takes station staff a year to implement the end result is much better for the station because when Telvue changes their Cloudcast URLs yet again or the IP address of the broadcast server changes, they can make the required changes.
Everyone involved in this project (including me) has been climbing the "Drupal ladder" and understands far more about Drupal and CiviCRM now than when they started. As a result we have a larger community capable of providing more support and more sites with more functionality than we've ever had in community media.
It is REALLY unlikely that any decisions anyone makes regarding VOD vendor, playback server vendor, Feeds, Media, Entities, etc would be the same when looking at implementing the same thing a year later. The Feeds based creation of VOD workflows you are describing is similar to what Bartlett Interactive and I configured for BNN when I wrote the original media_pegtv module. I documented that in (Using Media w/ Feeds (clean shaven) and Using PEG.tv w/ WYSIWYG (full beard) back in 2011.
While that configuration still works for BNN, we wanted to address that approaches shortcomings when implementing VOD for channelAustin. channelAustin's workflow will be the most automated and sophisticated playback/VOD integration I've ever seen, but it relies on a number of pieces of hardware, commercial services, and staff experience that other stations do not have.
channelAustin processed more than $100K in charges online for memberships, events, and donations. Their Cloudcast service is designed to be self sustaining. Cloudcast uploads will be handled by staff for members who pay an additional $5? a month. Implementing this workflow would not have been possible if channelAustin's staff weren't already managing producers logins to submit their own shows for 1.5 years, using basic Media integration for 1.5 years, CiviCRM to process payments for 1.5 years, pulling Airing info into Drupal with Feeds (1 year with Synergy, 6 mo with Telvue), updates to modules, Drupal, and CiviCRM via Difficult Starter Kit (6 months), and Pushing Shows to Telvue (3 months).
channelAustin is committed to sharing the code and the explanation of what they are doing with Telvue and VOD, but I'm not going to write a cm_telvue_media_cloudcast_archive_civicrm_project_show module that just makes the same configuration work for another station.
This is difficult. The number of moving parts, services, and code we don't control requires several people who understand how it works to keep it working. I can do a demo that makes channelAustin's VOD workflow look like magic, but I assure you it is anything but and has been years in the making.
If want feedback on what you are planning for RETN, keep posting your plans and I will continue to provide feedback as I have time. If there's something in the Difficult Kit that prevents you from achieving what you want, feel free to suggest changes (good) or submit patches (better). I've always responded to that too.
What I can't keep doing is spending time re-hashing the same discussion about how more planning and project management would result in something much better. This is the bazaar. Innovations will always happens on the fringe. If you want to build a site that populates both shows and vods from feeds provided by Telvue products, I can't think of any code or documentation I've written that would stop you. Correct me if I'm wrong, but I'm hasn't everything shared from the work done for or funded by Knight, BNN, PhillyCAM, AccessVision, and channelAustin only make what RETN is doing easier?
The bazaar approach to development is to just write the code, share the code, and THEN have the discussion about why the new approach is better. It isn't to require access to create new branches of modules before you contribute anything or hold back any improvements to the existing code until it is "done".
If RETN creates telvue_show_csv_import or some other module that does that, it could become popular to quickly and easily create Show nodes with VOD displays. Hopefully I've explained why that would be unlikely to ever be added to the easy level ket, used by the stations who are currently at the moderate level who've added Telvue from the difficult level, or even discussed by the only 2 stations currently operating at the difficult level.
Looking forward to seeing where RETN takes this.
A couple of things
are coming to the surface as I read over this healthy discussion. @kreynen - workflows do change and I trust that those committed to this project adapt. However, for the smaller orgs something like the VOD / Show changing from year to year is enough to break me. (I cringed when I watched http://vimeo.com/67261530 seeing a previous screencast from last year - sans beard - but excited by the new functionality.)
@emilyf - it does seem as though there may not be one solution - and it seems pretty clear to me that the solution is not going to be easy.
But, I do hold out hope that we can work together to find commonality across our organizations in terms of workflow. This is not to suggest that there is one ideal workflow. Perhaps this is something of an MOU among smaller stations (or a cluster of them). Over the past 18 months I have come to a much deeper appreciation of working in an open-source community. I truly believe that some other orgs will come around. But I think in my area - New England - with so many small stations - it would be wise to have some consensus on some aspects of the workflow. Of course there will still be different servers, different VOD providers, different staff capacity and budgets.
Maybe my choice of the words
Maybe my choice of the words "ideal" workflow should be rephrased - I definitely didn't mean that to be that there is only one option nor that everyone/anyone has to follow it. For clarity, I was mainly hoping for this discussion to document a current workflow for the entire group to better understand. This is definitely not just for RETN, though they, among others, would benefit from sharing a workflow. I was ultimately trying to do exactly what jdcreativity is saying, get some solutions up that others, especially smaller stations, can use as a guide. @kreynen - thanks for posting the Skype thread, as it shows, we do not get into details about the workflow (the goal of this thread) nor did our discussion benefit the whole group since no one else saw it.
While of course there are many ways to implement a workflow related to media (I posted about 3 options alone in the first post), and definitely because there have been so many changes to the media module, my hope for this thread was to help some stations to chose their approach or possibly use the same setup and thus better support each other when they run into issues. That was the goal here. Also, that goal is with you in mind @kreynen - your code contributions to this project are absolutely massive (thank you) and you have asked repeatedly for more help with documentation; so I wanted to get this out to the wider group and hopefully generate discussion, collaboration, and station-level support related to this piece.
As for RETN, as well as BCTV in Vermont, both will be using option B for the foreseeable future for this part of their media workflows. For other stations who want to implement this same (or similar) workflow but have questions or trouble with it, you can post here to talk it through together, or you can contact one of those stations for more information/guidance.