Skip to main content

TSBServiceMediaHandeler is created twice when recording is done followed by Service selection on the same service.

3 replies [Last post]
Joined: 2011-07-18

Hi Team

I have found a small issue while creating TSBServiceMediaHandler to start the player for service selection. In normal scenario TSBServiceMediaHandler is created and the player is started using that TSBServiceMediaHandler. But when we initiate a recording, just after receiving ENTRY_ADDED event if we initiate service selection for the same service, MediaHandeler which in this case is TSBServiceMediaHandler, is created twice and RI tries to start two different players for the same service. This is very intermittent.
Recording is initiated. ENTRY_ADDED event is triggered. Then Service selection is initiated on the same service.
RI Behavior :: DVRBroadcastServiceContextDelegate is instantiated and present method is called on DVRBroadcastServiceContextDelegate. Inside present method DVRBroadcastServiceContextDelegate will register for TimeShiftWindowChanged events and will try to acquire TSW by calling getTSWByDuration. As TSW is already there for the given service(Because recording was initiated for the same service) we will get the same TSW with BUFFERING as the current state. As TSW is in BUFFERING state sourceReady method (Private method inside DVRBroadcastServiceContextDelegate which is responsible for presentation) will be called. This method will create MediaHandeler(TSBServiceMediaHandler) and will try to start player for presenting the service.
In the attached log following is printed
20110629 16:28:08.159 INFO RI.Stack- 480673 [System-1] INFO service.ServiceMgrImpl - ServiceMgrDelegate org.cablelabs.impl.manager.service.DVRServiceMgrDelegate@75acf75d created a ServiceDataSource: - startMediaTime: Infinity, startRate: 1.0, service: null
20110629 16:28:08.175 DEBUG RI.Stack- 480688 [System-1] DEBUG service.ServiceMgrImpl - attempting to create a ServiceMediaHandler for dataSource: - startMediaTime: Infinity, startRate: 1.0, service: org.cablelabs.impl.service.javatv.service.ServiceImpl@d5499fd5[uniqueID=ServiceImpl430421880, locator=ocap://0x44c, handle=org.cablelabs.impl.manager.service.SIDatabaseImpl$ServiceHandleImpl@19a7b778[handle=19a7b778], name=HDNET, serviceType=UNKNOWN, serviceNumber=100, minorNumber=-1, lsData=null, locData=null] with ServiceMgrDelegate
20110629 16:28:08.222 DEBUG RI.Stack- 480735 [System-1] DEBUG player.AbstractPlayer - prefetch() [Unrealized-->Started]
20110629 16:28:08.222 DEBUG RI.Stack- 480735 [pool-26] DEBUG recording.RecordingImpl - RI 0x93417718: printSegmentInfo: Segment 0: details 0 @ 0ms: PCR PID 480
20110629 16:28:08.222 DEBUG RI.Stack- 480735 [pool-16] DEBUG lightweighttrigger.ProgramMonitor - PM 0xe30e72e3: isPresenting
20110629 16:28:08.222 DEBUG RI.Stack- 480735 [System-1] DEBUG player.AbstractPlayer - realize() [Unrealized-->Started]
20110629 16:28:08.222 DEBUG RI.Stack- 480735 [System-1] DEBUG player.AbstractPlayer - changing state from Unrealized to Realizing
AS DVRBroadcastServiceContextDelegate has registered itself for TimeShiftWindowChanged events, this delegate is also notified of READY_TO_BUFFER state change which will then call sourceReady method again.
In the attached log following is printed
20110629 16:28:08.362 INFO RI.Stack- 480876 [pool-19] INFO selection.DVRBroadcastServiceContextDelegate - TSWCL - READY_TO_BUFFER from TUNE_PENDING - calling sourceReady
As a result this method will try to create one more MediaHandeler(TSBServiceMediaHandler). This will cause failure while starting the player and below given error will be thrown
completePrefetching(failure- no controllable video device) - [Prefetching-->Started]
In the attached log following is printed
20110629 16:28:08.581 WARN RI.Stack- 481095 [pool-18] WARN player.AbstractPlayer - completePrefetching(failure- no controllable video device) - [Prefetching-->Started]
As a result presentation will fail and releaseAllResources will be called on Player. PresentationTerminatedEvent will be thrown with the reason: 3 (RESOURCES_REMOVED)
In the attached log following is printed
20110629 16:28:08.737 DEBUG RI.Stack- 481251 [System-1] DEBUG selection.DVRBroadcastServiceContextDelegate - stopPresentingWithReason - type:, reason: 3
Solution Purposed ::
In sourceReady method, a null check for MediaHandler(TSBServiceMediaHandler in this case) can be made before creating it. If it already exist we should not trigger the process again and method should return without doing anything. Otherwise the flow remains the same.
RILog.zip1.84 MB

Reply viewing options

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

Scott and I spent some time with this log today. It's close to a worse-case timing scenario.

The issue here is pretty serious. The Player code can be better guarded for dealing with the redundant notification. But more serious is this indication:

<span class="Apple-style-span" style="font-size: 10px; ">20110629 16:44:38.081 INFO     RI.Stack- 1470595 [pool-3] INFO  selection.DVRBroadcastServiceContextDelegate - TSWCL - got new state TUNE_PENDING (3) from RESERVE_PENDING (2), reason: NOREASON for TSWC 0x88583188:[nlist 1,ru org.cablelabs.impl.service.ServiceContextResourceUsageImpl@807849743[id=11127133,prio=220,,org.havi.ui.HVideoDevice,],tsw TSW 0x8594b67a:[service ServiceImpl430422640 (ocap://0x45a) ,state TUNE_PENDING,tuner 2,tbst 1426141ms,btsb none, nclients 1, TSC:[uses NO USES,res NI,mind 10,desd 0,maxd MAX_VAL]],constrain TSC:[uses NO USES,res NI,mind 10,desd 0,maxd MAX_VAL],1st tsb: none]</span>

Despite the fact that oldState is clearly incorrect, TimeShiftWindowClients should not expect to go from BUFFERING to TUNE_PENDING. This is a bug in the TimeShiftManager notification code. I'll provide a separate fix for this if/when the bug is submitted.

Joined: 2009-02-02

Would you mind filing a Jira issue for this issue?


Joined: 2011-07-18

Shall I raise a new issue traker for this issue.