We compiled workspace on the worker/encoder server and it goes to a directory on an nfs mount called workspace. I've used the file upload to try the reingest of the files. I haven't explored the inbox approach, though I'm reading about that now.
2012/4/11 Rubén Pérez <[email protected]>: > 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 > -- 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
