On 13-01-30 09:06 AM, Shane Phelan wrote: > > I'm checking out the HTTP ingest. Using the rest documentation I did > createMediaPackage first and then when using the REST documentation to > addTrack the file that gets created on the server is 0 bytes. The > response was 200-OK. Here's the info from Wireshark. > https://gist.github.com/4674044
Hrm, that looks right to me. Have you tried with with curl or wget? There might be a bug in the docs code itself. > The only thing weird that I see is the duration is set to 0, but > according to the documentation duration isn't required. Would a > duration of 0 cause the file uploaded to be 0 bytes? Nope, this isn't set by some of the other CAs, so I highly doubt it could break things like that. G > The file should be getting uploaded at the time addTrack is called correct? > > Thanks, > > Shane > > > On Mon, Jan 28, 2013 at 2:57 PM, Greg Logan <[email protected] > <mailto:[email protected]>> wrote: > > Someone brought this to me off list, and I figured I should put it up on > the main list too just in case someone else has the same question: > > > I'm doing some research on the Matterhorn capture agent and I was > using > > your Capture Agent wiki page as a reference > > > > http://opencast.jira.com/wiki/display/MH/Capture+Agent+Communication+Protocols > > > > One of the things you mentioned is that the HTTP ingest method is the > > better method and is encouraged to be used over the zip method, > but the > > reference capture agent still uses the zip upload. (Unless it was > > changed in 1.4) > > > > My question then is that statement still valid? Would you still > use the > > HTTP ingest method over the zip ingest method. > > Yes, for sure. The reason we have not removed the zip-based ingest > method is because some thirdparty CAs depend on it, and because no one > has had time to remove it yet from the reference CA. > > The issue with the zip-based ingest is that the CA has to spend a bunch > of time packaging potentially 10s of GBs of data, and then (more > importantly) the core has to unpackage it! This takes a while, and has > been known to reduce some storage configurations to smoking ruin. It > also has a bad habit of taking longer than many (proxy) systems are > comfortable with, which leads to problems like > http://opencast.jira.com/browse/MH-8884. > > G > > > > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
