I see. Then it's the 2GB upload limitation. The inbox approach works for arbitrarily large files. The failed mediapackages should be stored somewhere in your NFS share under a folder named failed.zips . Just open an ssh session to your admin server, then copy the zipped mediapackage into the "inbox" folder in your FELIX_HOME directory. A new war orkflow will automatically start. If you don't want to search through the failed zips, you can copy the zipped mediapackage from your capture agent instead.
Bear in mind, though, that this solves the problem of your files being trimmed when uploading them, but it does not solve the problem that caused the failure in the first place. Good luck Rubén 2012/4/11 Jack Vant <[email protected]> > 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 >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
