Skip to main content

Incorrect order of processing the events in RecordingImpl leads to have TSB conversion active even the recording is not active.

3 replies [Last post]
sivakumaran
Offline
Joined: 2006-05-05
Points: 0

There is a scenario where the native still continuing the TSB conversion even the respective recording is not active because of inproper processing of the events in RecordingImpl.
We have a testcase to verify the IN_PROGRESS_WITH_ERROR_STATE and IN_PROGESS_ INCOMPLETE_STATE recording transisions. For this, the testcase will create a MSV of very low memory and schedules a recording. On receiving the IN_PROGRESS_WITH_ERROR_STATE with space full reason, allocate few more memory which again results in space full error after resuming the recording.
1. There is no problem in staring a recording and TSB conversion initially. Once the space is full, the platform will notify RI [RecordingImpl.java] thru MPE_DVR_EVT_OUT_OF_SPACE. On processing the event, will trigger the TSB conversion stop in native[nStopTimeShiftConversion] and change the state of the recording to IN_PROGRESS_WITH_ERROR_STATE for SPACE_FULL reason. The state change notification was dispatched in caller context asynchronously.
2. The VerifyInProgIncompleteErrorSequenceDcli[testcase class] receives the recording change notification and verifies the expected state change and reallocating the MSV to have few more free space, which will trigger the notifications to MediaStorageVolumeUpdateListeners.
3. RecordingImpl is also a MediaStorageVolumeUpdateListener and the method notifySpaceAvailable() will be called in storage media worker thread. In parallel, RecordingImpl is a EDListener for DVR events, which receives the MPE_DVR_EVT_CONVERSION_STOP as result of calling the nStopTimeShiftConversion in point 2 above.
4. Now ED thread and storage media worker thread are trying to acquire the lock "m_sync" before processing the events. As per the logs, the storage media worker thread acquired the lock first and starts executing. The notifySpaceAvailable() method triggers the startRecording() to resume the recording by starting the TSB conversion and the recording state is changed to IN_PROGESS_ INCOMPLETE_STATE. The internal state now moved from IStateSuspendedInsufficentSpaceState to IStateStarted.The TSB conversion started again in native.
5. Once the storage media worker thread releases the "m_sync" lock, the ED thread acquires and calls the IStateStarted.handleNativeConversionStopped() method. This method moves the internal recording state to IStateEnded, which will remove the recording from Inprogress list, release NI, TSW uses, stop buffering, death timer activation and change the recording state to INCOMPLETE_STATE. Note, the native still continuing the TSB conversion for the service for the available buffer as we did not call the nStopTimeShiftConversion.
Because of the above problem, further attempts to schedule the recording on the same service fails with the below log,
"RI.Pipeline.TSB- tsb_convert -- TSB conversion already in progress
RI.Stack- <<DVR>> mpeos_dvrTsbConvertStart - Platform could not start TSB conversion!"
Please find the logs attached with this thread. Testcase class name VerifyStateCompleteSequenceDcli and which starts at line no 218738

Please correct if i am wrong.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sivakumaran
Offline
Joined: 2006-05-05
Points: 0

Any updates??

cpratt
Offline
Joined: 2008-12-18
Points: 0

I haven't looked at this with a fine-toothed comb, but I'd go ahead and file a bug for this.

sivakumaran
Offline
Joined: 2006-05-05
Points: 0

created IT621 for this.