Christoph,
Thank you for the reply! We have been testing on 1.4rc2, so maybe
things are improved.
In MH 1.4rc2, the episode's dublin core catalogs are still dereferenced
as "/0" when sent to the Engage during publish. The dereferenced mpeg-7
file's location path does not match it's one. For instance, the Id of
the resource in path name (i.e. "catalog-4") was used in the
dereferenced path but its not part of the actual path to the resource.
The correct dublin core resources path was constructed (except for the
file name) but not the mpeg-7. An mpeg-7/text flavored file generated on
our system is named "slidetext.xml". But, there is no obvious reference
to that file resource in the archived version of the mediapackage. It
seems like the new scheme might reference the slidetext.xml as
mpeg7.xml. I'm curious how it could defererence that back to
slidetext.xml (or maybe change the name to mpeg7.xml and put it in a
more streamlined path on archive)?
- Karen
On 9/28/2012 5:53 AM, Christoph Drießen wrote:
Hi Karen,
the "/0" is intended and describes the version of the episode in the archive.
But parts of Matterhorn -- namely the workspace -- do not like this schema without having
a file extension at the end of the URL. So as part of
fixinghttp://opencast.jira.com/browse/MH-9065 the new scheme will be something like this:
http://localhost:8080/episode/archive/mediapackage/d9c41616-f643-49e8-8b92-6d5f497eed21/track-1/1/track.mov
http://{host}/episode/archive/mediapackage/{mediaPackageId}/{mediaPackageElementId}/{version}/{type}.{fileSuffixOfMimeType}
Also the URNs you encountered in the database are correct. The episode service
acts as a long term archive so saving transient URLs does not make any sense.
That's why they are being rewritten to a location independent URN. But In fact
these URNs aren't currently used anywhere, they're just internal und should
remind the fact that this is an archived media package. If you access archived
episodes throught the episode service's REST endpoint these URNs are being
rewritten to point to the current location of the REST endpoint. By this
technique you are able to move the episode service (aka archive) to a new host
without any problem. Moving the archive to another host will likely happen in
the long run and that's something that has to be considered in terms of long
term archival.
Hope that helps,
Christoph
Am 27.09.2012 um 15:40 schrieb Karen Dolan<[email protected]>:
Does anyone else have the problem that in Episode Tab, episode details, all the URLs end
in "/0"?
Is it possible that workflows applied to an archive use the media package from
the episode_episode table? (Making all the meta-data meta-physical)
- Karen
On 9/27/2012 9:10 AM, Karen Dolan wrote:
I notice URN values in mediapackage within the episode_episode table:
<url>urn:matterhorn:c1dc4053-fdd5-4d0c-8143-d2608dfb216b:0:7213209f-6535-4d01-bf73-2fd8bf232add</url>
Normally, the url shows up as a location identifier in mediapackages. Does
anyone know if this is expected?
_______________________________________________
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]
_______________________________________________
--
Karen Dolan
Harvard University, DCE
617-998-8439
[email protected]
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
