On 12-02-12 05:14 PM, Dr Leslaw Zieleznik wrote: > > > I think about situation when recording is completed, but for some reason not > sent to core for processing, or processing is not properly completed.
The device will cache captures until it can send them to the core, however it has no way to know if processing was successful. Also, given the very limited internal storage space, the device deletes any capture which has been ingested successfully. Considering that the core will retain a copy of the original media I don't see a huge use case for this unfortunately... G > And so, I'd to resend it again. This might require access to ECD storage: > listing, deleting? I don't know what is possible, but at least option of > resending the last recording. > > Leslaw > > > > On 12 Feb 2012, at 22:03, Greg Logan wrote: > >> On 2/11/2012 8:34 AM, Dr Leslaw Zieleznik wrote: >>> Greg, >>> >>> The ECD is seems to be working fine! I made a silly mistake by typing a >>> wrong server address - we have two servers with a very similar name :) >>> >>> Anyway, ECD is starting and stopping fine, and more importantly there is >>> now a small delay between capturing and processing not like 35-40min delay >>> which was before. >>> >>> I am testing the ECD from home so I can't do a full test, for example the >>> video camera is switched off and I can only capture the PC screen. >>> I will do more tests on Monday and let you know of any problem. >>> >>> And another questions. >>> Can you extend the ECD functionality: >>> i) so the captured recordings can be send to the server, in case when >>> connection with the server is lost? >> >> I'm not sure I follow what you mean here... >> >>> ii) to allow start/stop recording by externally connected LCD panel, there >>> is such control implemented on this recorder >>> http://www.epiphan.com/products/recording/lecture-recorder-x2/ >>> But, that's probably very much up to the Epiphan decision? >> >> Yep, pretty much. Especially because LCD control panels typically >> require drivers (which wouldn't be built into the image, there are just >> too many of them). You would have to ask Epiphan about that. >> >> G >> >>> I am sorry for misleading you, >>> Leslaw >>> >>> >>> >>> On 10 Feb 2012, at 20:18, Greg Logan wrote: >>> >>>> On 12-02-10 02:09 PM, Dr Leslaw Zieleznik wrote: >>>>>> Is the ECD on a public IP? >>>>> I am afraid is not. But, I can try to look into or send you the logfile >>>>> if tell you me which part you are interested in. Can you wait with it >>>>> till Monday? >>>>> Otherwise I might reinstall the f/w again. >>>> >>>> Sure. The log file won't stick around until then though, it rolls over >>>> every little while. If you could just send me the whole logfile I can >>>> take a look. >>>> >>>> G >>>> >>>>> Leslaw >>>>> >>>>> >>>>> >>>>> On 10 Feb 2012, at 19:24, Greg Logan wrote: >>>>> >>>>>> On 12-02-10 12:05 PM, Dr Leslaw Zieleznik wrote: >>>>>>> >>>>>>> Yes, I definitely did, and rebooted after my setup, I did also rebooted >>>>>>> the server. >>>>>>> It worked fine before the f.w update. >>>>>>> It should not be affected that I am still on 1.2? >>>>>> >>>>>> The APIs have not changed between 1.2 and 1.3, so that should not have >>>>>> any affect. Is the ECD on a public IP? I can log in and take a look. >>>>>> >>>>>> G >>>>>> >>>>>>> Leslaw >>>>>>> >>>>>>> On 10 Feb 2012, at 16:58, Greg Logan wrote: >>>>>>> >>>>>>>> On 12-02-10 09:35 AM, Dr Leslaw Zieleznik wrote: >>>>>>>>> Greg, >>>>>>>>> >>>>>>>>> I have installed the patched f/w today and I have found, that: >>>>>>>>> >>>>>>>>> i) there is quite visible improvement in quality on both video and >>>>>>>>> VGA/DVI channels, which is a nice surprise! >>>>>>>>> ii) it is a slight shift to the right on both channels, which frame >>>>>>>>> grabber settings can't eliminate, bit I can live with it. >>>>>>>>> >>>>>>>>> But the problem is that, I can't start the capture agent though it is >>>>>>>>> registered on the core. It stays idle all the time, and at the capture >>>>>>>>> start time I am getting the message: >>>>>>>>> >>>>>>>>> ""WARNING : Recording may have failed to start or ingest! >>>>>>>>> It seems the core system did not receive proper status updates from >>>>>>>>> the Capture Agent that should have conducted this recording"" >>>>>>>>> >>>>>>>>> I did try to start recording many times with different setup on the >>>>>>>>> agent, changing the pooling interval, ingest interval and also stream >>>>>>>>> setups, without any success. >>>>>>>> >>>>>>>> Did you reset the device to factory defaults after updating the >>>>>>>> firmware? This is something that needs to be done every time you >>>>>>>> flash. >>>>>>>> The version I posted works as expected for me... >>>>>>>> >>>>>>>> G >>>>>>>> >>>>>>>>> >>>>>>>>> Is it anything else I can try? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Leslaw >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 8, 2012, at 10:20 PM, Greg Logan wrote: >>>>>>>>> >>>>>>>>>> On 12-02-05 11:52 AM, Dr Leslaw Zieleznik wrote: >>>>>>>>>>> >>>>>>>>>>> I'd like to notify about the problem we have noticed during the last >>>>>>>>>>> week recordings. >>>>>>>>>>> >>>>>>>>>>> Our observation is that when the capture time is longer then 45min, >>>>>>>>>>> the workflow remains in the PAUSE state - the Capturing displays the >>>>>>>>>>> status Capturing - and it stays like that forever. >>>>>>>>>>> Otherwise the capture agent behaves properly, changing the status >>>>>>>>>>> from Idle to Capturing and back to Idle correctly with the recording >>>>>>>>>>> time. >>>>>>>>>>> >>>>>>>>>>> I suspect this is something to do with the current ECD f/w, so we >>>>>>>>>>> simply need to wait for the coming rel 2.3? >>>>>>>>>> >>>>>>>>>> This is really odd, I'm seeing that behavior as well. The file is >>>>>>>>>> captured, but during ingest it is not included in the zip file. This >>>>>>>>>> causes an exception during ingest if you check your core's logs. >>>>>>>>>> This >>>>>>>>>> functionality worked before, so the only thing I can think of is that >>>>>>>>>> the zip tool changed underneath me. The current firmware version >>>>>>>>>> contains an error in the ingest scripts which is actually losing that >>>>>>>>>> data. I have created a patched firmware version available at >>>>>>>>>> http://aries.usask.ca/epiphan/ which will prevent the loss of data, >>>>>>>>>> however the underlying issue of passing the data to the core remains. >>>>>>>>>> I've sent an email to Epiphan about this and I hope to hear back >>>>>>>>>> soon. >>>>>>>>>> >>>>>>>>>> In the mean time, I would install the above firmware (which includes >>>>>>>>>> the >>>>>>>>>> new features I outlined at Oxford). >>>>>>>>>> >>>>>>>>>> G >>>>>>>>>> >>>>>>>>>>> Leslaw >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Matterhorn-users mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Matterhorn-users mailing list >>>>>>>>>> [email protected] >>>>>>>>>> <mailto:[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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> Dr Leslaw Zieleznik >>>>> OBIS (Oxford Brookes Information Solutions) >>>>> Oxford Brookes University >>>>> [email protected] >>>>> Tel: +44 (0)1865 483973 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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
