As you know, workers copy the files they need to process from the workingfilerepository, and the put back the resulting files afterwards. This process may be done in two ways: either all the files are shared between all the machines, so from Matterhorn's perspective files are always "local" to the machine, or they are requested via the REST endpoints to the machine that *actually* has the files.
This behaviour is not dynamic, either it works one way or the other. Specifically, when you compile the source code, you need to specify either workspace (which means "my media files are in a shared volume") or workspace-stub (which means "files need to be requested via the REST endpoints). In the first case, there's no theoretical size limitation in the files. In the other, there may be hiccups with files bigger than 2GB, and there was also a bug recently solved that was also "trimming" to 2GB any big file transferred. The vast majority of adopters use the first schema, so that 2GB limitation is nothing for them to worry about. However they may still be problems when *uploading* (ingesting) big files, if they are longer than 2GB, by similar reasons (related with web browser support). Are you using the inbox to reingest those failed recordings? Or are you perhaps using the Upload File menu? 2012/4/11 Jack Vant <[email protected]> > We have five machines involved in our Matterhorn installation, an > admin machine, a worker that does the encoding, a dedicated engage > server and 2 streaming servers behind a load balancer. We do use > shared (nfs mounted) storage. We are version 1.2. What do you mean > by "have been build with the > > workspace --rather than the workspace-stub -- profile"? > > 2012/4/11 Rubén Pérez <[email protected]>: > > In some cases there are problems with files bigger than 2GB. Sometimes > those > > errors are avoidable, sometimes aren't. I corrected myself a couple of > bugs > > in the WorkingFileRepository service (I think that was the part, but at > > least it was related), which directly affected the processing of videos > > (trimming them to 2GB if they were bigger). This is fixed in trunk, but > did > > not make it to 1.3 . > > > > I wonder which version are you using and if *all* the machines in your > setup > > use a shared drive to process the videos (and have been build with the > > workspace --rather than the workspace-stub -- profile). > > > > Regards > > > > 2012/4/11 Jack Vant <[email protected]> > >> > >> We have a professor here who utilizes Powerpoint presentations with > >> large numbers of slides and imbedded in the presentations are youtube > >> videos, so the track for the presentation video is quite large, 1.2 > >> gigs on average. Several of her captures have failed during > >> processing and reingestion fails and the mpg for the presenter > >> computer is blamed. The last two lectures for this class processed > >> just fine but the last 10 minutes of one lecture and the last 5 > >> minutes are not viewable, the video freezes and the audio along with > >> it. These lectures are an hour and 15 minutes. Have we hit some > >> threshold? > >> > >> -- > >> Jack Vant > >> System Engineer - Unix > >> Office of Information Technology > >> Boise State University > >> 208-426-4446 > >> 208-863-0031 > >> _______________________________________________ > >> Matterhorn-users mailing list > >> [email protected] > >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > > > _______________________________________________ > > Matterhorn-users mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > > -- > Jack Vant > System Engineer - Unix > Office of Information Technology > Boise State University > 208-426-4446 > 208-863-0031 > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
