If I understand it correctly: 1. The scheduler will keep sending ALL the catalogs in the iCal file. 2. It's up the the CA implementations whether to send those catalogs back to the server or not. -- But this may cause data inconsistencies if the scheduled metadata is changed and the agent starts the recording before polling the new data from the scheduler. 3. Those catalogs which are sent back "overwrite" those that are kept in the server.
I've got some remarks here: 1. The synch problem explained in 2) is a more general issue. Perhaps we should somehow check the agent's polling time and lock changes to the schedules that will surely not be updated on time. In the end, it all goes down to the communication protocol between server and capture agent --either we change it completely so that the core can activelly poll the agent or we assume the limitations of the current model and deal with them. 2. What happens if, in the agent, one decides to remove the series from that recording? The agent may remove the series catalog... but then it will be restored in the core. I know this is a rare use case, but it's worth pointing it out. 3. I assume that if the agent sends more catalogs which were not formerly present in the schedule, those are still added to the new workflow and kept in the mediapackage. Am I right? In other words: "The resulting mediapackage will contain all the files contained in the Capture Agent's mediapackage and in the 'waiting' mediapackage in the server, with the files in the Capture Agent overwriting those already present in the server". Assuming my 3rd remark is correct, I'm +1 for this proposal. Otherwise I'm -1 and I #propose that to be included in the former Tobias' statement, so that it gets my positive vote. Regards Rubén 2012/6/20 Pawel Fic <[email protected]> > Well... that was not my point. > > Well, my point is to write down what mediapackage should contain. > Right now, it's: > 1. episode/dublincore > 2. series/dublincore > 3. tracks - as many as you want, but at least one. > > Other than this - ID's and MD5 sums are optional, and that I will write > down a proposal for the commiters to approve by the end of this week (and > since this Friday it is the last day of school here, I may be busy - so end > of the week includes weekend). > > > I love the proposal of making series/dublincore optional in few cases, and > I think server should decide how to enrich / alter mediapackage when it is > ingested rather than forcing overwriting the data - however overwriting is > one way of handling it. > > > Best Regards > -Pawel > > > --- On Wed, 6/20/12, Tobias Wunden <[email protected]> wrote: > > > > The mediapackage already is completely universal, you can > > attach anything to it, including catalogs that contain > > YouTube or Videolecture.net specific information. It just > > happened that we decided to have our own scheduling system > > create dublin core catalogs, but you can easily implement > > your own. Just make sure that in this case you implement a > > MediapackageMetadataProvider implementation that is able to > > provide a subset of metadata to the mediapackage (see that > > interface for more details, it's essentially the title, the > > series and some other things). > > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
