Skip to main content

Recording failures due to the lack of sync b/w stack and Gstreamer clock

10 replies [Last post]
srinivasrk
Offline
Joined: 2011-10-31

We found an issue with Recording in our TDK testing. While doing Pre-requisite recording setup in TDK. (TDK does the pre-requisite recording setup before starting the test suite in DVR enabled RI. Basically It records one SD recording, one HD recording and one Low_bandwidth recording.)
One of the recording (recording on HD channel) duration is 90 seconds. We are seeing the below message throughout this recording duration.

RI.Pipeline.TSB- tsbConversionStateStarting -- Conversion state = TSB_STATE_CONVERSION_STARTING
RI.Pipeline.TSB- tsbConversionStateStarting Nothing to convert yet (bc:1338990647300718844 ec:1338990648553540005 cst:1338990717287000000)

At the end of the recording, as there is no recorded content the recording is getting transitioned to FAILED_STATE. I guess this might be the problem with Gstreamer clock.
Our RI is merged with CableLabs code till the revision 31924.

I am attaching two logs one for specific to that failed recording and one for the complete log. Please have a look and let us know whether this issue is fixed in the trunk in the later revisions or not. If not shall I raise the IT?

Note: This issue is observed only in windows platform.

AttachmentSize
Logs.zip296.27 KB

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
smallman
Offline
Joined: 2004-06-19

Issue posted. Please add new comments at:

http://java.net/jira/browse/OCAP_RI-658

smaynard
Offline
Joined: 2009-01-27

From your log:

TSB begin clock: 1338990647 == Wed, 06 Jun 2012 13:50:47 GMT
TSB end clock: 1338990648 == Wed, 06 Jun 2012 13:50:48 GMT
requested conv. start time: 1338990717 == Wed, 06 Jun 2012 13:51:57 GMT

Since the requested time is after the end clock of the current TSB no conversion will take place.

What is your TSB duration set to?

srinivasrk
Offline
Joined: 2011-10-31

Actually recording starts when the Recording Start Timer spec is triggered. So when the recording comes to native layer recording conversion start time should be in between the TSB's beginning clock and end clock.
But in this case, I am getting that message (Nothing to convert yet..) continuously through out recording duration (90 seconds). It means that there is a huge time gap between TSB clock and recording start time.
To answer your question: I have not set any TSB duration. I just created ServiceRecordingSpec with a source id, start time as current time and duration as 90 seconds. After that I have passed this ServiceRecordingSpec to RecordingManager.record(spec) method and waited till the recording completes.
Please let me know if you need more information.

smaynard
Offline
Joined: 2009-01-27

Can you tell me what RI.Platform.dvr.IfsChunkSize is set to?

srinivasrk
Offline
Joined: 2011-10-31

'RI.Platform.dvr.IfsChunkSize' value is unchanged i.e. 600 seconds.

srinivasrk
Offline
Joined: 2011-10-31

Any updates on this?

smaynard
Offline
Joined: 2009-01-27

I have not been able to reproduce this bug and I don't understand why the conversion amount is 1 second. If you are still seeing this on the current trunk - please capture full logs and attach them to a new Jira issue.

abysubin
Offline
Joined: 2011-07-31

Hi,
I too observed the same issue as reported above, while running recording state change test cases (TC0646,TC0179,TC0651,TC0337 of TDK) on CL revision r36321. All the test cases are failed. Two logs are attached here with - One of TC0179 alone, and the complete log . I have enabled the 'Pipeline' module to DEBUG mode and 'Gstreamer' to INFO level.

This failure is observed after the introduction of new GStreamer plugin. I have tested with older CL version before this and it is working fine. On analysing the check-ins made in 'OCAPRI/branches/new-gst' branch, i could see two revisions which were meant for correcting this issue,which are as follows:

r30594: Setting the GST system clock to be REALTIME (rather than the new default of MONOTONIC)
r31586: Win32 Fix of setting the calibration of the system clock to be systicks from epoch

I have seen your post in GStreamer forum too (http://gstreamer-devel.966125.n4.nabble.com/GST-system-clock-question-td...)

But even after these fixes, we are able to see these failure in Windows XP machines (which are located in UK) consistently. But the same issue is not seen in Windows XP machines running in India. Does time zone and/or DL savings have any impact during this calibration calculation? During calibration, we are using system API 'gettimeofday' which takes time zone as second parameter. We are passing it as NULL.

smaynard
Offline
Joined: 2009-01-27

from the gettimeofday man page: "The use of the timezone structure is obsolete; the tz argument should normally be specified as NULL. The tz_dsttime field has never been used under Linux; it has not been and will not be supported by libc or glibc. Each and every occurrence of this field in the kernel source (other than the declaration) is a bug. Thus, the following is purely of historic interest."

I was considering this calculation purely as UTC. We are looking at the calculation again to see if there is a mathmatical error...

rwahlers
Offline
Joined: 2012-07-19

I ran these TDK tests today at Cablelabs and they're all passing for me.

It may be better at this point to open a jira issue and attach your logs there so that it may be properly addressed.