On 12-06-18 12:22 AM, Kristof Keppens wrote: > On 06/14/2012 07:53 PM, Greg Logan wrote: >> On 12-06-14 01:32 AM, Kristof Keppens wrote: >>> 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. > > I'm testing this on a 1.2 core at the moment, we are planning upgrading > to 1.3.1 for the next semester. If I understand correctly, even with the > 1.3.1 core this problem may occur, it may just take a bit longer before > it happens? We normally have captures of around 2 hours, 2 or 3 in a row > with a short break between them. Will the device with an 1.3 core be > quick enough to keep recording, ingesting and cleaning this number of > captures before filling up again?
No, the ingest method for 1.3 skips the ingesting step, so as long as the device can ingest faster than it records you should be ok. For instance, I test with three captures in a row, 2:50 in length, with 10 minute breaks between them and these succeed. The issue you are describing says to me that the 1.2 ingest method (which tarballs the source media) is taking up too much space when combined with multiple recordings. Alas, this is just a limitation of 1.2. You can set the device to use the 1.3 ingest methods, however this *will* cause duplicate rows in the admin UI (fixed with 1.3.0), and the lectures will process with the default workflow regardless of your settings in the scheduler (fixed with 1.3.1). These are both Matterhorn bugs unfortunately, so the only way to fix them is to upgrade! G >>> 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 > Great, some remote logging would be a great help! We will wait a bit > until we moved to 1.3 servers and test the device again then. > > Kristof >> >>> Thanks >>> >>> Kristof Keppens >>> _______________________________________________ >>> 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 > > > > > _______________________________________________ > 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
