On 12-06-14 01:32 AM, Kristof Keppens wrote: > Hi List, > > After a while we decided to start testing the epiphan devices again with > the latest firmware from epiphan's site ( 2.3.1e1 ) . Our results so far > aren't really promising. The first day of recordings went relatively > successful, 3 captures, around 5 hours together was ingested successful. > We did notice than when setting the stream setup to picture in picture > the ingested material is also picture in picture and not 2 separate > streams. For the second day of testing we changed the setup to 2 > streams, however none of those recordings made it to the server, idem to > the recordings for the third day.
I have seen similar behaviour with my devices when my *cores* ran out of space. Do you have free space remaining for your cores? Other than that the devices with that firmware have performed very well in my testing. > I have in the capturing overview in matterhorn 2 recordings from the > second day ( the third recording that day doesn't even show there ), one > stuck in capturing and one stuck in sending recording to processing. For > the third day only 1 recording made it to the overview, also stuck in > sending recording to processing. > > In the logs of the epiphan device I notice a message for the recording > stuck in capturing that says unable to save recording ( or something > similar ) and for the first recording of the third day a message keeps > appearing that says trying to ingest, and zipping to /u/data/, this > repeats for a while and at last it will disappear only to start all over > again. Is this testing with a 1.2 core, or 1.3? The 1.3 core (and newer) does not require the zipping step, and this saves half of the storage space on the device that you would otherwise need for zipping the files up. It sounds to me like the internal storage is full, and this is preventing the zip-based ingest from functioning properly. Unfortunately I don't think there's a user-accessible way to clear the disk right now. Is the device on a public IP? I can log in and wipe out whatever is on it for you. > The test recordings are scheduled as follows : > 10:00 -> 11:45 > 12:00 -> 13:55 > 14:00 -> 14:45 > > And this 5 days in a row. Could it be possible that after the first 3 > recordings ( that succeeded ) the disk is full and therefor creating > this problem or are we doing something else wrong. Another question is, Yes, this is quite possible. In my testing I have three devices each capturing a 2:50 minute capture, and I can only have each device capture three times before I fill up my cores. It's entirely possible that capturing a long capture on the device can also take up enough space that the device will be unable to ingest properly with a 1.2 core, however there just isn't anything I can do since the fix for this changes the ingest API. > is there already a way to login to the epiphan device and directly see > the current and past logs there cause the device log page has it's use > but it would be useful to be able to see all logs to pinpoint the issue. Not currently. The device doesn't keep much in the way of logs unfortunately, the memory precludes this. I'm hoping to get some remote logging stuff done in the near future which would alleviate this issue. G > Thanks > > Kristof Keppens > _______________________________________________ > 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
