Hi, > Another copy of the files? So now we've got the distribution copies, > in its own mediapackage; the working file repository copy, in its own > mediapackage too; the episode service copy, also in its own > mediapackage. And we are going to add *yet another* copy for the > archive service. So that makes four *different* mediapackages > refering to the very same recording! No wonder why it's so difficult > to keep track of the files.
Knowing nothing of the episode service I must ask, does it have its own copy of media package resources outside of the WFR as Ruben suggests? An archive service the way I envision it pushes raw media packages away from MH. E.g. to reprocess them you need to pull them out of the archive. Does someone want to drop the link to the wiki space that describes plans for the archive service (I know there was something floated by Tobias previously). > sufficient? Why don't we keep things in synch with the "episode" > copy? I mean, what's the point of "archive" being an optional > operation you can include or not in your workflow? How wouldn't > anyone want to keep their recordings archived and ready for being > processed again for whatever reason which may come in the future? To me archive means slow storage, and everything else means fast storage. So archive is tape storage, or cheap but low performance disk arrays, while other things are on a high speed SAN with high availability. > > will be making about how much disk space Matterhorn requires. So I > > disagree with Tobias in that this matter is not only relevant to > > those who are already designing their pilots, but also to those who > > are considering whether or not they are interested in deploying > > such pilots. We should publish estimates based on per-hour of recording. This is what we did internally, and it makes it much easier to talk about scaling things. For those interested, here were our estimates: For engage I looked at one directory and it had: - roughly 350MB vga, - 350MB ntsc, - 60 MB audio - other metadata total: roughly 800 MB for a 1 hour lecture. We have three copies of this data, so it works out to be 2.4GB/capture. 13 weeks of courses, 3 courses per week: 13*3*2.4=96.3 GB/course So, for each course we want to add we need 100GB of live disk space attached to our engage server. Worspace for workers is much smaller though, since we process then delete the media packages, and the first thing we do is push them to tape (which is "so big we don't care" how much space is used). Chris -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 Mail: Advanced Research in Intelligent Educational Systems Laboratory Department of Computer Science University of Saskatchewan 176 Thorvaldson Building 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
