Skip to main content

RecordingFailedException is overrided from SPACE_FULL to INSUFFICIENT_RESOURCES for FAILED_STATE.

10 replies [Last post]
pradeepngupta
Offline
Joined: 2011-07-03

UseCase: To track the recording state passes through IN_PROGRESS_WITH_ERROR_STATE (due to SPACE_FULL) and then FAILED_STATE (due to SPACE_FULL).

For the above usecase, I have created 15MB of MSV & schedules a recording of 5 min, which will fill the MSV completely. When this recording goes to IN_PROGRESS_WITH_ERROR_STATE (due to SPACE_FULL), I am scheduling one more recording of 1 min and waiting for the second recording to be over, so that any extra space in the MSV even after the first recording fills, will be completely filled by the second recording.

Now, I am scheduling the third recording of 1 min and tracking for its states for the above use case.

Note That, all the three recordings I am scheduling is on the same service.

Now, what happens is the Third recording is going to IN_PROGRESS_WITH_ERROR_STATE due to SPACE_FULL & recording is transition to IStateSuspendedTunerUnavailable after releasing its TimeShiftWindowClient. The first recording was still not over, so from IN_PROGRESS_WITH_ERROR_STATE , it started again & trying to see if any space is available on the MSV to record. On failing to freed up the space, this recording again goes to the IN_PROGRESS_WITH_ERROR_STATE & release all its resources. Due to this, NI Offer is raised and listen by the third recording. The third recording is now acquiring the NI to start the recording before checking for free space. While it acquiring the NI, stop spec is getting fired since 1 min of recording duration over.

This stop spec was handle by IStateSuspendedTunerUnavailable which is transiting the third recording to FAILED_STATE and overrided the FailedException to INSUFFICIENT_RESOURCES. This I observed few times when running the RI Simulator on Windows.

I certainly agree that this might be an edge case for the threading issue. But i am able to reproduce it more frequently with default log.

If I am enabling the DEBUG logs, I am not able to reproduce the issue.

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

Sorry - I think this slipped off the radar.

I think there is clearly a bug here, and possibly more than one.

The CTP tests do not contain any "disk full" tests that I'm aware of. And I don't believe the DVRTestRunner "disk full" tests have been run in some time.

I think the root of the cause the lack of a state for recordings suspended due to space being unavailable (e.g. IStateSuspendedSpaceUnavailable) - which will retain the tuner much like IStateSuspendedTunerNotReady.

Please file a bug so work can begin on this right away.

pradeepngupta
Offline
Joined: 2011-07-03

Thanks Pratt for the reply.

I have raised the JIRA issue:

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

Regards,

Pradeep Gupta

pradeepngupta
Offline
Joined: 2011-07-03

I am repeatedly getting this error.

Anyone having updates on this.

Regards,

Pradeep Gupta

pradeepngupta
Offline
Joined: 2011-07-03

Hi All,

Is There any update on this?

Thanks & Regards,

Pradeep Gupta

pradeepngupta
Offline
Joined: 2011-07-03

Hi! All,

Is there any updates on this??

Thanks & Regards,

Pradeep Gupta

svikrant
Offline
Joined: 2011-02-09

Hi Pradeep,

As per my understanding of your problem :

User Initiates recording : Recording state is IStatePending then it transitions to IStateWaitTuneSuceess where TSB starts and Recording conversion begins. The state is transitioned to IstateStarted.

Now in IstateStarted, the user created MSV is full, So TSB conversion is stopped and the RecordingState is updated to IN_PROGRESS_WITH_ERROR_STATE with reason SPACE_FULL and the new IState will be IStateSuspendedTunerUnavailable.

Now RI will attempt to resume the recording by offering resource and the recording will be reinitiated and the same state transition will begin.

Now Coming to your Question : Expiration of EndTimer (Stopping of recording).

This end timer can expire in any of the above states as mentioned above : IStateWaitTuneSuccess, IStateStarted, IStateSuspendedTunerUnavailable.

If the stop spec is expired in any IStateStarted or IStateSuspendedTunerUnavailable : Any previous failed exception will be retained ( except if its UserStop or failure reason is unknown).

So in these two states, previous recording failure reason (e.g SPACE_FULL) will be retained when the recording is over.

But in case of IStateWaitTuneSuccess : The previous recording failure reason will be ignored and will be overridden with INSUFFICIENT_RESOURCES directly.

I think this is a bug in handleStop() method in this State. This method should check previous reason and retain any existing reason except when reason is Unknown (i.e) :

if (m_info.getFailedExceptionReason() == RFE.REASON_NOT_KNOWN){

setFailedExceptionReason(RecordingFailedException.INSUFFICIENT_RESOURCES);

}

If the group member feels otherwise, please let me know.

cpratt
Offline
Joined: 2008-12-18

It's highly unusual for a recording to fail (or stop) while a tune is pending for a reason other then a tune failure. I think this is a good change to make (having IStateWaitTuneSuccess.handleStop() not over-ride an already-set RecordingFailedException) - but I believe this is really a secondary issue.

The best solution is to introduce an IStateSuspendedMSVFull state which would (a) not release the tuner (which it shouldn't be doing - according to spec), (b) watch for the MSV changes that will make the recording resume, (c) set the RecordingFailedException correctly (and only if it's not already set). Due to (a), the third recording in this scenario will not be started since the tuner will be held for the duration of the RecordingRequest (or until the tuner is lost due to contention).

Spec reference: DVR I06 section 6.2.1.1.3.3 (Resource Requirements)

  • All resources required for implementation of a recording SHALL be held for the duration of the recording, unless lost due to resource contention with another activity. For example, the tuner resource that is required for a recording should not be implicitly released if the target service was not accessible due to CA restrictions.

pradeepngupta
Offline
Joined: 2011-07-03

Hi! Pratt,

I think this is better design.

I am starting the third recording only after second recording is over, so my test will not fail bacause of this change.

Thanks & Regards,

Pradeep Gupta

srinivasrk
Offline
Joined: 2011-10-31

Hi Pratt,

With this fix, when the MSV got filled completely, the recording is going to IStateSuspendedInsufficientSpace and the reason for the failure is not getting overridden to INSUFFICIENT_RESOURCES. Now we are getting the correct reason SPACE_FULL. But there are some issues with the fix for the below case:

Start a recording on MSV, MSV gets filled with the recording, then recording goes to IN_PROGRESS_WITH_ERROR_STATE with reason SPACE_FULL, after that we reallocate the MSV space so that the recording can continue. The recording should transition back to IN_PROGRESS_INCOMPLETE_STATE.

Issues:

  • As part of this fix, a FreeSpaceListener is being registered with alert level 5 in IStateSuspendedInsufficientSpace. At the same time TSB conversion is stopped. In the current RI implementation, the free space alarms get fired only when TSB conversion is going on. Once it is stopped free space alarms will not get fired. So IStateSuspendedInsufficientSpace will not get notified with the free space available on the MSV. So the recording is not transitioning back to IN_PROGRESS_INCOMPLETE_STATE. We have tested this with TDK test case TC0651.
  • You are registering FreeSpaceListener with alert level 5. That means you will get notified when the free space level drops below 5. What happens if the free space level is made 50 by reallocating the MSV? You will not get notified until that get drops below 5.

I propose that instead of FreeSpaceListener, we can use DVRStorageManager.MediaStorageVolumeUpdateListener to notify the space changed on the MSV. So when ever user reallocates space for an MSV, we need to notify the registered classes which implements DVRStorageManager.MediaStorageVolumeUpdateListener. This fix will solve the above problems, but still not sufficient for the below case:

  • When an MSV got filled with 2 recordings which are in turn transitioned to IN_PROGRESS_WITH_ERROR_STATE with reason SPACE_FULL, If the user deletes one of the recording then the other recording should get notified that there is some space available on the MSV, so that it transitions back to IN_PROGRESS_INCOMPLETE_STATE.

For this case, whenever the recording is being deleted, we need to notify the registered classes which implements DVRStorageManager.MediaStorageVolumeUpdateListener from the RecordingRetentionManager.

I am attaching the patch file (with .txt extension) with my fix.

srinivasrk
Offline
Joined: 2011-10-31

The above issues are found in RI 1.2 as well by running TDK test TC0651. Same behavior is observed in RI 1.2 also.

Any update on this issue?