search

teltek / Galicaster

The Galicaster Project is an open initiative to provide flexible, state-of-the-art solutions for recording educational multimedia contents like lectures and conferences
galicaster.teltek.es
Other
35 stars 31 forks source link

Mediapackage Id not set correctly in galicaster #6

Closed miesgre closed 12 years ago

miesgre commented 12 years ago

Mediapackage Id not set correctly in galicaster

1.- Program a new episode in matterhorn 2.- Galicaster records that episode Galicaster greates a new folder named gc{agentname}{workflowid}

Check that galicaster is using the workflow id for folder names... In that folfer the manifest.xml is something like this:

.... Galicaster is putting in the mediapackage ID thw workflowId and not the mediapackageId that must be something like 2c32c4d5-7216-4ea3-9749-5820d1edde3a The same happen in episode.xml
rubenrua commented 12 years ago

Using workflow_id as the mediapackage_id is not a problem. The official capture agent does the same (please see the method determineRootURLandID in RecordingImpl.java).

The problems lies in the very Matterhorn processing. When a recording is scheduled, MH creates a new workflow and an associated MediaPackage with a new mediapackage ID. Then, the iCal sent to the capture agent has a new event with that recording's information (episode.xml, org.opencastproject.capture.agent.properties and series.xml). The event ID is the same as the workflow ID, but the capture agent doesn't know the ID of the MediaPackage associated to the workflow to be recorded. That's why the agent uses the workflow ID as a MediaPackage ID (on the agent's side).

When the new MediaPackage is ingested, the capture agent tells the core to resume the corresponding workflow instance. Then, the admin, after decompressing and processing the .zip file, takes the MediaPackageElements (Tracks, Catalogs, Attachments, etc.) from the MediaPackage just received from the Capture Agent and includes them in the MediaPackage created when the recording was scheduled, discarding the Capture Agent MediaPackage afterwards (see the existingMediaPackage variable in IngestServiceImpl.java). This is why the IDs are different --they are indeed different MediaPackages.

The funny thing about this is that if you try to ingest that MediaPackage for a second time, Matterhorn does not use the indicated workflow because it's already "FINISHED". Instead, it creates a brand new workflow and this time it uses the ID provided by the Capture Agent for the new MediaPackage.

We are going to propose this as a bug in Opencast's JIRA, and work on it to fix it.

miesgre commented 12 years ago

Thanks Ruben, can you post the issue link here, so I can follow it!

Thanks!

sinhote commented 12 years ago

A ticket has been filed in the Matterhorn JIRA to track this issue:

http://opencast.jira.com/browse/MH-9282