Omneon API and Scheduled Ingest
In the case of using the Omneon API driver to ingest media through the Etere Ingest - Scheduled ingest module (i.e. which allows scheduling consecutive recordings to be performed automatically), it could happen that the Omneon device, at a certain point of a series of scheduled recordings, it gives an error due to an internal problem of the device.
If encountering problems in this scenario, Etere suggests to disable the Omneon API driver (i.e. via IP) and set back the default Omneon driver (i.e. via RS422 using the VDCP protocol), all this under the Etere's Resource module, and then save the device log and send it to the Omneon's technical support services.
The following logs illustrate both cases of a successful and a failed 'recording cue' execution, respectively:
------------------------------------------------------------------------------------
In this case, the cue and recording are performed correctly without any error message (i.e. 0x00000000):
06/04 10:31:14:690[17] 000788113562 0418 OmPlrAttach
(0x015D9EA8,1104061030,0,153001,0,omPlrShiftModeAuto,0xA25B8178)=0x00000000
[TOmneonPlayerAPI.PrepareEncoding] [TSISMedia.MediaLog]
-------------------------------------------------------------------------------------------------
Notice how, at this point, Omneon's counter starts replying slower and slower (i.e., higher reply values) until it stops replying definitively (i.e. zero reply value):
06/04 10:49:06:523[13] 000789185437 0418 OmPlrGetTime1(0x015D9EA8,25310,0,0,0,0,0,0,0)=0x00000000) [TOmneonPlayerAPI.GetPosition] [TSISMedia.MediaLog]
06/04 10:49:06:554[14] 000789185468 0418 OmPlrGetTime1(0x015D9EA8,25311,0,0,0,0,0,0,0)=0x00000000) [TOmneonPlayerAPI.GetPosition] [TSISMedia.MediaLog]
06/04 10:49:06:585[15] 000789185500 0418 OmPlrGetTime1(0x015D9EA8,25312,0,0,0,0,0,0,0)=0x00000000) [TOmneonPlayerAPI.GetPosition] [TSISMedia.MediaLog]
06/04 10:49:07:393[10] 000789186312 0418 OmPlrGetTime1(0x015D9EA8,0,0,0,0,0,0,0,0)=0x00000000) [TOmneonPlayerAPI.GetPosition] [TSISMedia.MediaLog]
At this point, the third clip doesn't start; the recording cue is fine, but when the REC command is sent, the following error is received:
06/04 12:32:15:141[04] 000795374140 0344 OmPlrRecord(0x0862DEF8)=0x0000900E [TOmneonPlayerAPI.Rec] [TSISMedia.MediaLog]
06/04 12:32:15:141[04] 000795374140 0344 !!! Error reported by device: [0x900E wrong state] [TOmneonPlayerAPI.DeviceError] [TSISMedia.MediaLog]
Clips with zero-based timecode / non-zero-based timecode
In Data Mover, It was noted that the duration of specific clips had changed after being copied to the ETX station; the SOM of the clip was not set to zero when the clips were copied using the workflow action "After Ingest ETX". The SOM only reset to zero after the customer responds (click <OK>) to the warning message "Physical start does not match with the one in the archive".
The SOM problem can be overcome by setting the drivers in the OMNEON video server:
•OMNEONAPI: Select this driver to manage clips with a zero-based timecode.
•OMNEONAPITC: Select this driver to manage clips with non-zero based timecode.