Skip to main content

tsb reset is not implemented in native

1 reply [Last post]
ssathish
Offline
Joined: 2011-05-26
Points: 0

I am running an application which performs,
1. Select a service and buffer it for 20 seconds.
2. Change the player rate to -1x speed (rewind operation).
3. Wait for 30 seconds duration to receive BeginningOfContentEvent.
4. Destroy the service context.
5. After service context destroyed, wait for 5 seconds to give interval for next run.

The execution is successful for first run by receiving BeginningOfContentEvent within 30 seconds from service selection started.
For next time run, the same application gets failed consistently (step3) for not receiving BeginningOfContentEvent within 30 seconds duration.
Also, in fail scenario the tsb duration shows 94 seconds which is expected to be less than 25 seconds as we are buffering for 20 seconds duration.

The execution gets failed due to tsb is not getting flushed when TimeShiftbufferImpl.reset() is invoked from TimeShiftbufferImpl.returnTSB() method while performing service destroy operation.
The reset() method has a 'TODO' note stating "Flush the contents of the native TSB (when there's a way to do that)"

Kindly confirm, whether Cablelabs will provide fix for the unimplemented tsb reset method in any upcoming release.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cpratt
Offline
Joined: 2008-12-18
Points: 0

[Sorry for the delay - I misinterpreted this question the first time I read it.]

The documentation for mpeos_dvrTsbBufferingStart() isn't sufficient, but currently it's presumed that any pre-existing content in the referenced buffer is cleared as part of the call. In other words, mpeos_dvrTsbBufferingStart() starts with a "clean slate". I don't know what platform you're on, but likely the issue is that mpeos_dvrTsbBufferingStart() is not clearing the TSB prior to buffering.

The MPEOS API change to retain the contents of the buffer across multiple Stop/Starts() - along with a buffer reset/flush - would enable the stack to utilize a single buffer to contain content from multiple media times and even multiple Services. This would allow for more efficient use of TSBs and support cross-Service buffering (the optional TimeShiftProperties.setLastServiceBufferedPreference() feature). However, there hasn't been enough demand for this feature to justify the engineering required to support the changes required. The TODO you're referring to TimeShiftBufferImpl.reset() represents one of the many changes that would be required.