Skip to main content

RecordingFailedException with reason RESOURCES_REMOVED

11 replies [Last post]
kpradeep
Offline
Joined: 2011-01-24
Points: 0

As per OCAP DVR Spec section "6.2.1.1.3.3 Resource Requirements" Table 6-2, when access to the media storage volume is removed RecordingFailedException with reason code RESOURCES_REMOVED is generated.
When removeAccess(String organization) method of MediaStorageVolume is used, RecordingFailedException with reason code INSUFFICIENT_RESOURCES is generated. But as per the spec the reason code should be RESOURCE_REMOVED. Is this an issue with RI?

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

Yes - I believe this change was missed as part of the ECN-1076 implementation - which added section 6.2.1.1.3.3.
Go ahead and file a bug for this. It looks like a straight-forward fix.

tarunra
Offline
Joined: 2011-02-16
Points: 0

Hi All,
INSUFFICIENT_RESOURCES is reported for 3 other scenarios as well:
1. When RecordingManager.disableBuffering() is called, and there is a background recording happening, and is in IN_PROGRESS STATE. disableBuffering() will stop the recording and will report the RecordingFailedException with failure reason as INSUFFICIENT_RESOURCES.
2. If XAIT is received with a new IMA (InitialMonitorApp) pending to launch and there is no InitialMonitorApp currently running. In that case, it will stop the ongoing recording with failure reason set to INSUFFICIENT_RESOURCES and will restart the app.
3. While launching IMA, if the new state is reported as NOT_LOADED, it will stop the ongoing recording with failure reason set to INSUFFICIENT_RESOURCES and will restart the app.
Could you please confirm, if the above said behaviour is as expected, or should the reason be RESOURCES_REMOVED?
Thanks,
Tarun

kpradeep
Offline
Joined: 2011-01-24
Points: 0

Thanks

tarunra
Offline
Joined: 2011-02-16
Points: 0

Could someone please clarify the above doubt regarding 3 other scenarios, where INSUFFICIENT_RESOURCES is reported?

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

In the context of DVR, Section 6.2.1.1.3.3 (Resource Requirements) provides the most clarity regarding the application of the RecordingFailedException codes.
[see table 6-2 from OCAP DVR I06]
With the following catch-all language: "Except where otherwise specified, INSUFFICIENT_RESOURCES SHALL be considered a non-specific reason."
Since disabling of buffering via OcapRecordingManager.disableBuffering() is not in this list, this language requires INSUFFICIENT_RESOURCES reason to be recorded/reported.
[This is probably moot, however, as I don't believe recording is supposed to be terminated due to a call to disableBuffering() - since the javadoc states: "If an implementation uses time-shift buffering for recording creation it MAY segment the recording." This definitely implies to me that recording continues. I will file a bug for this.]

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

I'll get you an answer for (1) later today.

svikrant
Offline
Joined: 2011-02-09
Points: 0

For 1) when disable buffering is callled. Why the recording should stop ? This is a separate USE of TSW (TSWUSE_RECORDING) which should exist independently and should not get affected if we disable buffering. I feel recording should continue if user disables buffering.

tarunra
Offline
Joined: 2011-02-16
Points: 0

While setting the failure reason for failed recording, should we overwrite the reason set earlier?
Or, should we check if the reason already set is REASON_NOT_KNOWN, then only overwrite with the new failure reason?
Please, clarify.

svikrant
Offline
Joined: 2011-02-09
Points: 0

I think the recording failed reason should always give the last reason which caused the recording to discontinue. Is it not so ?
If Not, Is there any concept of priority among the RECORDING_FAILED_EXCEPTIONS ?

tarunra
Offline
Joined: 2011-02-16
Points: 0

Hi All,
Could someone please clarify the above doubt?

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

Sorry for dropping out of the conversation there. I stopped receiving forum notifications for some reason.
There isn't a concept of priorities certainly. According to section 6.2.1.1.3.3 of OCAP DVR I06:
. "The implementation SHOULD record the most specific reason code in a generated org.ocap.shared.dvr.RecordingFailedException."
The RI currently sets the RFE to the first failure encountered. While this isn't technically against spec (since this is a SHOULD), this should probably be corrected.
I think this makes the most sense. Presumably, an application will examine the exception upon seeing a RecordingRequest go into the FAILED or IN_PROGRESS_WITH_ERROR states and expect the RFE to reflect the condition that caused the state transition.
I'll file a bug against the RI to change its behavior to be compliant with the above text. If anyone feels this should be a SHALL, please chime in.