Hi Greg, Hi Tobias,
in a way I would really appreaciate it to have the mediapackage in the
filesystem, especially when it comes to backup or exporting the data,
but I see the concerns that it will have heavy impact on the overall
design of the system.
But wouldn't it be an option to dublicate the mediapackage in the
filesystem currently as a first start to this issue? The mediapackage
methods could simply write the new mediapackage to the WFR whenever the
MP got updated. In later versions of Matterhorn we could than easier add
methods to import the MP or change the whole MP-processing.
Regards
Rüdiger
Am 03.10.2012 17:51, schrieb Tobias Wunden:
Hi Greg,
as discussed during the meeting, it may or may not be a good idea to move the
mediapackage xml out of the database. The idea of it being in there is that the
mediapackage is an argument to the 'start workflow' operation, and the service
registry and its job dispatching facility stores the arguments for service
calls in the database so there can be failover.
If we now move the mediapackage out of the db onto the filesystem and replace
the db entry with a file:// or http:// url instead, job dispatching can be
completely broken by cleaning up the working file repository or random places
on disk.
From my point of view, this suggest investigating whether there is a datatype
that is better suited such as a BLOB or anything similar, since Matterhorn only
uses the field for later reference, not for querying, searching or the like.
Tobias
On 29.09.2012, at 00:02, Greg Logan <[email protected]> wrote:
Hi folks,
I have a question for those familiar with the job architecture: Why do
we store the mediapackage xml in the jobs table? Why not a link to the
file in the filesystem? I have multiple captures here which overflow
the payload column during distribution. Everything else works, just
this particular piece of media appears to have a lot of scenes. I am
uncomfortable changing the segmentation settings since they obviously
work fine as is. I'm processing this lecture instead as a
presenter/source to avoid the scene detection, but this is an extremely
wasteful workaround.
I'm tempted to propose that we should move that file onto disk where it
belongs in 1.5, but I'm not familiar enough with the jobs architecture
to say for sure. Could those who are more familiar with it (Tobias? :))
chime in and give me a hint of how much work is going to be involved here?
Thanks,
G
_______________________________________________
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]
_______________________________________________
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: [email protected]
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
