Right now if you try to install both the Station Module and PEGevent module on the same site you end up with a name conflict for the CCK type Program. For Station a program is a period of programming that has similar content (e.g. the Access Hour, Blues Cruise or The War and Peace Report with Amy Goodman), so that is a bit different than program on PEGevent module.
I wonder if PEGevent would be open to a patch that would rename the Program type within PEGevent to the PEGevent Type. This idea would leave the Showing type alone. A further change would be to change the descriptions available to the user so that there would be less confusion, but an initial change would be to only make the change at the drupal content type level.
I think of this as an initial step towards bringing the Station and PEGevent modules so that they complement each other. PEGevent would be the way that programs are scheduled and Station would be how they are displayed to the public.
If this should go someplace else, my apologies. I did not have any luck with the issue tracker.
Comments
Name Confilct and Module Function
I chatted about integration of Station and PEGevent w/ Drewish at DrupalCon Boston. Not sure if they are integratable. If Station meets your needs go with it. To see a schedule based on PEGevent go to http://www.cctv.org/watch-tv/channel-17-schedule: lots of detail w/ long names and all sorts of durations: not sure if the Station display code would work for this.
PEGevent is a lot more detailed, specific and flexible on scheduling: down to the second. Station (when I looked at it long ago) was more useful for half hour to hour slots w/ regular repitition. That said, Station was out there first and PEGevent probably shouldn't step on that namespace. I think ultimately, the user should be free to choose the name of the "Program." You could hack the pegevent.install file, but I'm not sure how to make this easy for non-hackers. Can you get user input in the .install file? Is that a good idea?
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Confused - What is the point of this entire module?
I'm confused about the point of the PEGevent module. I read the module page and walk-through, and neither seems to provide much in the way of capabilities or optimizing workflow. I'm really unclear how this would help us? Can you clarify?
Here is my workflow so far:
1. Enter the programming data on a piece of paper (with correlating user signature) to authorize playback of the content.
2. Enter programming data from the paper into the playback system (Synergy in this case).
3. If I've done it right, I might also enter a program record in Facil (since I would like to be able to report on the relationship between training, equipment use, and programming generated, not to mention keeping track of who submitted the program) -
4. Then I had to make a program schedule in Excel to give to the ED and board, publish to the non-Internet community. -
5. And I had to enter the program data grid into TV Guide.
6. And I'm also supposed to enter the same data into PEGevent so that my programming data can be available real time on the website.
Essentially, PEG staff are now spending most of our time handling non-automated recursive data tasks - task which computers which were designed to do "for us". Yet in order to crank up the "cool factor" of our websites with "tools" like PEGevent, we are actually assigned MORE recursive data entry, instead of the tools working "for us".
No wonder PEG is getting killed by Comcast and Time Warner - the lack of efficiency here is pretty mind blowing.
To top it off, very little of this data helps me get any closer to a metadata or a DCMI capable schema (dublincore.org), and I can't even share programming info (minimizing data entry) with partner stations who might play the exact same program.
At least station seems to provide some functionality - the integration with streamripper would provide functionality if we were a radio station. Perhaps we might recruit someone from the VideoLAN project or FFMPEG to help us in the video space?
Don't get me wrong, I appreciate the time and effort you guys have put into this. I know form having done CCK work in the past that this is no picnic. I guess I am hoping for closer alignment with PEG priorities and a real awareness of the challenges we face.
Frankly, PEGevent seems like a dead-end to me.
If you want to help PEG, build some modules which tie to existing data sets, or which help minimize data entry. Then we'll have more staff time to help more people create programming.
With respect,
videohead
The point is to reduce data entry.
Videohead,
Let me try to explain a little more clearly...
The point of pegevent is not to increase data entry -- that would be stupid and ridiculous! The point is to reduce data entry. By doing so, in many cases it will require some workflow changes as well. Here is an ideal pegevent workflow:
You or producers fill in some program info ONLINE (NOT ON PAPER!). That starts a program in Drupal and pegevent. The program gets a Drupal node id (unique identifier).
You manually enter in the Drupal node id to your master control system (in a custom field). The only other info in master control at all would be MPEG-2 filename/location, exact duration (from an encode) and maybe a program name.
The exact duration and mpeg-2 filename get exported to drupal (automatically in some cases).
You do all your scheduling in pegevent.
pegevent exports a playlist to your master control system which then takes in the playlist and starts airing programs.
All of this said, pegevent at present is only compatible with MaestroVision. Now, before you stop reading, I am as we speak making additions to work specifically with the synergy system. So, if you do anything like my synergy station, here is what the initial stages of workflow will look like.
First, Synergy is one of the more limited systems in terms of the backend. Also, last time I checked synergy is weak on imports (it does playlist imports but not program info). I may be wrong on that second part, and if I am, great. It will get better integrated. But here's where I'm at right now:
You or your producers start your projects/programs/intake forms in Drupal/pegevent (you fill in program info, producer, etc etc etc). That starts a program.
When your program gets ingested to Synergy, you create a title number and appropriate msn information there (in synergy). This really does need to be done in Synergy and not drupal. You do not fill in any other information in synergy. Just the basic necessities.
Once the program has a title number in synergy, you manually assign the drupal program a title number (it has to be manual since there is no way for Drupal and synergy to know they are the same program). That's all the redundancy there is (one number).
Here is where my module will then support multiple workflows.
Option 1:
There are 2 daily exports from Synergy. One from the VLM events and one from the title/program database. The field orders will most likely have to be set (at least initially). The program export will contain all msn info (and there is the option for all the other fields too, but if you start by entering programs in drupal you shouldn't be using synergy for all other info) and automatically update all this information in Drupal.
The events export will be just that, and it will get auto-ingested into Drupal which will in turn populate pegevent airtimes. Then it will magically connect your airtimes and your programs, etc.
So option 1 is there to support how most people are probably working now -- scheduling directly in synergy and wanting auto update of program info and air schedules online. It also supports exports of all program data in case people are not starting programs online, and instead starting all the meta data entry in Synergy. This is not the ideal workflow, but it will be supported.
Option 2:
There is one daily export from synergy and one daily import TO synergy. The export is the program data containing msn information and exact durations which will go automatically into Drupal based on the synergy title number that you manually enter to drupal.
The import TO synergy is playlists from pegevent (using pegevent to do scheduling) in Drupal.
Right now option 1 is essentially up an running at one station in Vermont. But it's still a little dirty on the code end and I have to port it either into pegevent code or as an add-on module that taps into many of the pegevent features (which may just be easier). Hopefully it will be all set in a few weeks time.
Option 2 will happen in time. Not sure how long, but if the station I am working on this for wants that ability, or if joegml has to set that up for a specific reason, it will happen sooner rather than later.
Anyway, if you're interested in finding out more about this, reply with any questions/comments/suggestions you might have. My goal is to make it applicable to all synergy users (TO REDUCE data entry time) who are using Drupal. I would love for it to help you out.
In terms of Facil, an integration goal for the peg-related modules is to take care of all of that. The hope is that by using pegevent and OpenFlows/MNN's reservation module, you will be able to achieve everything facil can do and more. The reservations module will deal with equipment checkout, and all the 'contact' pieces are dealt with through CiviCRM (a robust contacts management system module that is available at civicrm.org).
Hope that helps.
Facil replacement - and yet
It would be interesting to create an export file that matched Facil's data fields only for the sake of access centers that would want to have a transition period between systems AND for the fact that both the TRMS and PSG servers accept Facil export files. You would be creating a very easy first step for both those playback systems to integrate with Pegevent.
Is any of this going to be explored at the ACM Conference in July?
Facil match
Yes indeedy. Iowagirl you've got the right focus . . . but I think that train already left the station.
The fact is, import-export is the old way of doing business . . . aren't we supposed to be > web 2.0
Seamless data integration is how it all should work. If you've got to import-export daily then you are only as good as your last import-export, and that means you can only make scheduling changes daily.
No thanks.
Between XML-RPC and RSS we're ready for the new paradigm - we can now all expect it to just work, and to work better than it used to.
A few lines PHP talking to a smidgen of VB.NET and bingo-bango-bongo your data should be inside and outside the vlm.mdb and facil.mdb without having to go flat file on their asses.
Who decided I should use a stateless medium to communicate with a core app, when I have a stateful app right there on the scheduling computer?
Don't understand that lack of logic - bad fundamentals.
Anyone know what the average time to load a Drupal page is, once my leeetle HTTP packets make it through all that crap javascript?
I won't be in DC in July, but will be exploring stuff.
videohead, In all
videohead, In all seriousness, you sound like you would be the perfect person to integrate my synergy work with vlm.mdb and facil.mdb. I've already written almost all of the nodeapi integration code, and it's only lacking in that at present it is just taking a synergy export. If it's really only a few lines of code as you suggest, we could be up and running in no time. I think it's a great idea...
How about it? I think comments/discussion/arguments are all good and we should keep em comin, but providing skills on development where you have them is even more valuable. Want to join up?
I'll be talking a lot about
I'll be talking a lot about the suite of modules we're building along with Emily & Sean during the Drupal session at the upcoming July conference. I'm sure we'll also have some BOF/similar sessions. We're currently in process of generalizing our ingest & auto-scheduling modules and starting to look at how we might integrate PegEvent, as well as MNN's equipment reservation & class scheduling modules. Kevin (kreynen, just started this week here at Civic Pixel / Deproduction and is focused almost full-time on this project) and we should have a better roadmap/outline of our project early next week at which point we'll post it as a wiki to this group. I agree with comment below made by videohead in regards to leveraging XML-RPC, RSS, etc and we're moving in that direction with the servers that support it (PSG so far, but hopeful that others will provide similar APIs as we start writing more plugins). We'll also be supporting basic import/export operations, and we'll look into Facil's export format...more updates to come as we get organized over here.
Open Media Foundation
In case you are wondering how I got roped into this . . .
Hi Emily (SW9),
Thanks for your thoughtful and reasoned response. Excellent points.
Sorry if it seems that I am throwing the baby out with the bathwater vis a
vis PegEvent. Not having run it through its paces, I don't really know what
it is capable of. Obviously, your intent is to make the ingest and
programming management interface easier to work with, and minimize data
entry. Great!
From the BOG perspective, I see (and have seen) some considerable
limitations with what I perceive as this particular tack on software
development that I would like to address. I think a core focus on needs
assessment and documentation is ABSOLUTELY essential to the PEGspace
project as a whole, and this seems to me to be something that is missing
from the project.
Regarding PEGevent - in working with the limitations of CATV programming
scheduling interfaces, it is my tried and true belief that if you don't
comprehensively assess the capabilities of a system, it doesn't matter how
GOOD your new interface is, it will not likely be accepted by the
community, or will be nominally accepted and the community will remain
fractured across multiple platforms. This is why there are still PEG
centers running Leightronix.
Also, any system MUST address metadata, and from my perspective your
system does not. I'm not sure if you've worked in a library or with
extensible data schemas, but I feel that you should definitely check what
the DCMI folks are up to in regards to this. See dublincore.org
Most importantly, from my perspective, the import-export model is broken -
that's THEIR model for how you can/should interface with their apps. They
PWN'ed U! C'mon . . . aren't we > Web 2.0?
Seamless data integration must be a core part of apps we develop. That
means reaching into the data flow directly and not requiring additional
steps.
Not sure if you are a PERL person or what, but a decent .NET developer
could reach into that vlm.mdb in a heartbeat.
In working within the limitations of Facil, I feel that the same approach
must be applied. As much as I hate Facil as an interface (OMG was this
thing designed on stone tablets?? What IS that interface even called . . .
besides ugly?), the fact is IT WORKS! That's because Dave Becker knows PEG
- he knows the models, he knows the training, he knows the user base. He
can support it, and he can still sell it.
Respectfully,
Matthew (videohead)
Subject: Re: [groups.drupal.org] Great response
Hey Matthew,
First, let me make this clear: I am NOT the pegevent developer. I am an independent consultant in Vermont working with PEG centers to create solutions for video and content delivery and integration solutions between MC and the web. In particular, I work in Drupal to develop the front end, integrate it with CiviCRM, and find VOD solutions that can be as automated as possible. One of the stations I work with is CCTV (Vermont), and they hired Joe Golden to write the pegevent module. They hired him to do a custom remake of their old mysql C++ front end and to put it online. So the original plan on pegevent was a custom built module for them. It is now expanding since there is functionality for it on a wider scale.
I only come into the picture because I am now participating in the future of pegevent, and I have personally decided to work on a Synergy solution for a particular station in Vermont. I don't want to rewrite pegevent, so I am building on its functionality.
The biggest problem with PEG access is this: Everyone says we can do needs assessment and find a big solution, but it's not true. I have worked with pretty much every PEG center in VT, and EVERYONE wants to do it differently. Everyone uses their master control systems differently. Everyone does meta data differently (if they are even doing it at all).
The issue this presents is that it makes it difficult to provide catch all solutions. Facil has tried, and it has worked to some extent, but now people are growing tired of its limitations, too.
That said, we can't just sit and dwell on that issue. We have to get up and provide other solutions. We have to try to change people's workflows so there is no more pen and paper whenever possible.
Anyway, enough of my rambling. I think you are an asset to the future of this module, and I appreciate your comments (you may want to continue commenting on the pegspace group so others can participate in this discussion).
So you said pegevent doesn't address metadata....can you elaborate on that? Feel free to use your station as an example.
The way I see it, the metadata should reside in Drupal where it can be viewed and manipulated by peg stations and their producers and users, and only what is necessary for MC should go to MC. MC is a playback system (unless you are using a VOD solution with your vendor for example), and if it is as limited as Synergy is, then why put more effort into it than you need to. Drupal is your dynamic interface AND it can act as your archives.
With that said, I did mention that the Synergy module I am writing WILL automatically ingest metadata into Drupal if Drupal isn't being used as the entry point.
I know some perl, but it's not really my strength, and most heavy drupal developers recommend against using it vs. php so that you can use nodeapi to do things the 'drupal way'. But you are right that you can get into vlm.mdb; for my module right now I don't see a huge need for this. But if you really want metadata to come into Synergy, then that would be applicable...want to pay for it or develop it??? :)
As for the dublincore mention, I am familiar with it. There are lots of meta data options out there. At present, there is an ACM workgroup that has been working with all vendors willing to participate who are going to make their systms PBCore compliant. Right now that includes Tightrope, Leightronix, Princeton Server Group, Rushworks, and MaestroVision. Some folks are frustrated that the group has decided to use PBCore instead of Media RSS or DublinCore, and I echo those sentiments (I really like Media RSS). But the issue is, a year ago PBCore was the way everyone said to go, and it happened. If we keep changing every 3 months we won't get anywhere. So the hope is to start here and then aim for compliance with other options, too.
This is a very productive discussion and I thank you for your comments. Are you going to the national conference? If so, perhaps we can chat in person!
Thanks,
Emily
On Thu, Jun 26, 2008 at 12:25 PM, Matthew Galvin matthew@activematrix.org wrote:
Hi Emily,
Thanks for the clarification and for keeping the information flow going. You are right on!
You should celebrate (and be celebrated) for developing something that alleviates the challenges of the particular station in Vermont.
In this case, lead by example (and case study), as this trumps needs assessment –if you've already solved the challenges faced by that one station, then you are a hero – end of story.
So write a case study about what you've done and let the people follow – or don't.
As far as global needs assessment – it does exist. You may not have seen it in VT, but VT is one slice of the very big pie, which includes ALL of the players in the P, E, and G spaces.
Even though we all pick different solutions, and adopt different standards, the overarching needs are to streamline workflow and provide access to our stakeholders – right?
I agree that you can't make a catch all, but you can try to catch the best and lead by example.
PBCore will probably be probably a good example of this – yes it is not perfect and I agree that Media RSS kicks its butt as far as multimedia. . . but it has met the global need and found some adopters, and frankly if we can't figure out how to transfer data to-from very similar schemas, then we probably don't belong in this field anyway.
With metadata you have to start somewhere, and anywhere is better than just entering the title field, which is how most people make it through the day.
I hope that we can do better than PEGEvent. It is poorly documented and badly explained, with only one set of half-assed screenshots that I could find. There is no development thread and no issue tracking. If this thing was on Sourceforge it would be DOA. If it works for optimizing workflow, it doesn't seem to address needs that I have identified. If I wasn't asked to implement it, I wouldn't have bothered. I probably won't bother to continue with it, although your commitment to it has probably changed my mind on that.
Thanks for the insights and dialogue – I've got a lot of respect for your obvious commitment and passion to the field, and I mean what I said about you being a hero.
Do you mind if I post this back to the PEGEvent thread?
I won't be at the ACM conference (probably ever again), but I am going to get roped in to the pegspace stuff and will continue my lurk and snipe subroutine.
If you need help with the Facil or VLM schemas, hit me up. Those MFs at Synergy still owe me $8000, so I'd like to stick it to them – any way I can.
- Matthew
Hey Matthew,
By all means feel free to post it back to the discussion (I will then post this one back, too). I think everything is important for everyone to see!
In terms of the VLM stuff, YES I am interested (see the post I made to pegspace a few minutes ago...). If you can write some integrate with vlm.mdb, I would be STOKED. The past week I have just written a Drupal node api php script that mocks an old perl script we had here. It takes a synergy .txt export and feeds the data into Drupal to create, delete and update nodes. Over the next week I plan to finalize it and put it into an actual module instead of a standalone script (or if I'm lazy I will just include the file in the pegevent module folder....).
One of the things I have been struggling with is my extreme desire to streamline things for others rather than continue on this path of customization. It's great job security for me, but it is the exact opposite of what my vision is. I want to help PEG stations grow into the future AS CHEAPLY AS POSSIBLE. I want it all to be free. The stuff I'm working on with my script is kind of specific again to the workflow here, so in my head I have been trying to figure out what kinds of configuration options I could put on a module that would allow it to be easier to manipulate and put elsewhere....
So yeah, I'd love any help you're willing to offer. If you're saying you're in, how do you want to proceed?
Thanks,
Emily
Actually I want to use both PEGevent and Station
I believe that Drewish would say that Station and PEGevent have different purposes (http://drupal.org/node/191686). Of course you have actually talked to him and I am still trying to figure out how to integrate modules to do what I want. So far I am thinking that PEGevent is focused on scheduling and Station is focused on interacting with the public. The future events in Station are where DJs put in their material but it is so that their listeners will know what is going to happen or what is currently happening rather than for controlling the station. So the overlap is in pegevent_public_schedule(). I do want the public schedule to be created from the private (for want of a better term) schedule.
Assuming I am not misunderstanding, a program for PEGevent is a block of content (The Utah Phillips retrospective). A program for Station is a block of time into which content can be scheduled (The news block, or The Blues Show). What I like about Stations concept of a program is that specific people have privileges to alter the programing in the specific timeslots for their shows and they cannot alter other timeslots. Do you have any suggestions about adding/merging that into PEGevent?
I don't think the user needs to name what is now the program data type. They do, of course, need to be able to name the programs they create (whatever program comes to mean). Technically PEGevent just needs to change the CCK type currently known as program to a different name. It could be PEGprogram, but I suggest pegshow. I did what turned out to be close to a search and replace on PEGevent.install and PEGevent.module and that has mostly worked (for some reason the pdate is not getting set).
My first thought was to change data type from program to pegevent. I think that would work but I quickly realized that was going to create a mess. Since PEGevent is the name of the module, then when you read the code, it will be unclear if pegevent is referring to the module or to the data type. I suggest the data type be called either pegshow or just show (I have used pegshow). I suppose some might think it is too close to the type showing, but I like the idea of a show and a showing (or possibly even a showtime). This would fit well with popular usage -- especially when thinking of a movie or play. There are possibly several showings (or showtimes) of the same show (movie).
Changing the name to avoid a name collision is the first step. Changing the text and documentation is a bigger task. I have not done anything with that pending your thoughts about the name.
Namespace
Eric,
would it suffice to change the interal CCK type to pegprogram? Does the collision happen on name, type or the combo of the two? How many people will be installing both of these modules together?
\$content[type] = array ('name' => 'Program',
'type' => 'program', # change to 'type'=>'pegprogram',
I'm trying to consider the general case. The name "Program" is what folks in the TV biz call these things. "Show" does sound too much like "showing", although there is the noun/verb thing which is kind of nice.
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Namespace type is what is important
Yes this change (and the corresponding changes in the module) will remove the php/drupal conflict. There is still the issue about the difference of the terminology (program as a timeslot vs program as a piece of content). I guess how important consistency is depends on to what extent these modules become complimentary (the integration I have worked on has not made much progress, in part because of other time demands) or if each evolves to encompass the functions of the other.
yeah, i agree each module
yeah, i agree each module should stay within its own name space. that was the rationale behind my change in the newer versions of the station module.
Look at 5.x-2.x
The 5.x-2.x branch has renamed all the node types to be station_* to avoid any namespace issues. The code should be pretty stable I'd been holding off on creating a release until I found some time to get the archive supporting multiple schedules.
Namespaces
Drewish,
we're working on a generalized D6 Pegevent. It will use Drupalesque table prefixing as you suggest. So rather than "Showing", content type will be "Pegevent Showing" and at the DB level "content_type_content_showing" will change to "content_type_content_pegevent_showing", etc. Hopefully this will help avoid collisions.
I'm a bit slow, but moving in the right direction ;-)
--
Joe Golden :: www.triangul.us :: People, Ideas, Connections
Joe Golden :: www.triangul.us :: People, Ideas, Connections