> > So far I don't know of any capture agent that supports changing metadata > locally
Galicaster does. We use it all the time (in the Oxford Unconference, for instance, we would edit the metadata as the recording was going on). > , and the scenarios that we have been discussing on list recently seem > artificial, however not completely off. A class is scheduled but the administrative services do not know which topic is it about beforehand. The teacher updates the metadata as he/she desires on the spot, so that no further communication is needed with the administrators to set the right title/description/etc. right. The teacher wants to include some comments or remarks on whatever interesting have occurred during the class, which was not foreseen: some answer to a student's question, which turned out to be very instructive, for instance; or correcting some mistake made in the lecture which the teacher notices before the class ends (even though it's corrected later on, you can expect some students to see the mistake but miss the part where it's corrected). We schedule some unconference sessions, of which we know the length, but not the subject. The device is set to not ingest the recordings automatically. After the sessions, an operator edits the fields of the recordings and ingests them. Not saying that cannot be done in the core afterwards, but this may save some trouble (specially the first scenario) because the professor does not have to contact the media services to correct some typo/add some metadata to their classes --they just edit that themselves. Or not. But at least there's a choice. 2012/6/20 Greg Logan <[email protected]> > On 12-06-20 06:58 AM, Tobias Wunden wrote: > > Hi Ruben, > > > >> If I understand it correctly: > >> • The scheduler will keep sending ALL the catalogs in the iCal > file. > >> • 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. > >> • Those catalogs which are sent back "overwrite" those that are > kept in the server. > > > > this is from my point of view an exact summary of the proposal. > > > >> I've got some remarks here: > >> • 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. > > > > By design there is no communication between core and capture agent that > is initiated by the core, since in many cases, the capture devices will not > be reachable from the outside world (including the core). > > The CA pushes its configuration to the core however, and one of the > configuration items is the polling interval (at least for the reference > CA). I don't know about the vendors though... > > > _______________________________________________ > 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] _______________________________________________
