Skip to main content

Recording states

4 replies [Last post]
Joined: 2010-09-21

In RecordingRetentionManager.evaluateAvailableSpace, if free space in msv is 0 (i.e. msv.getFreeSpace() returns 0) then the state of the recording is set to IN_PROGRESS_INSUFFICIENT_SPACE_STATE but as per spec [OC-SP-OCAP-DVR-I05-090612: I.11 Use Case: About to start and insufficient space for recording] the state should be IN_PROGRESS_ERROR_STATE. Is this an issue? Should there be a check explicitly for msv.getFreeSpace() to set the state to IN_PROGRESS_ERROR_STATE?

Reply viewing options

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

To clarify, IN_PROGRESS_INSUFFICIENT_SPACE state is used for RecordingRequests which are recording but are not expected to complete due to space. IN_PROGRESS_WITH_ERROR is used for RecordingRequests which are not recording due to any number of conditions (but who's end time is still in the future).

The RI should transition the RecordingRequest to IN_PROGRESS_WITH_ERROR upon receiving the MPE_DVR_EVT_OUT_OF_SPACE notification. In the case you describe (where there's 0 space), this should happen immediately upon starting the recording process, but I see this functionality is missing currently. I'll file a bug for this.

I wouldn't change the logic in RecordingRetentionManager.evaluateAvailableSpace() however. It's easier to handle this in one place (the async event handler) rather than two. And RRM doesn't have sufficient visibility into the RecordingRequest state machine.

Joined: 2008-12-18

Actually, I misread some of the code.
The RI is actually transitioning into the I_P_W_E state on a space full indication (and setting the RecordingFailedException to SPACE_FULL).
As I described above, this should be happening nearly immediately after recording is started (if no space is purged as part of the RR startup).

Joined: 2011-02-09

Hi Pratt,
In RI when we call startRecording : we initiate the native call for TSB to Recording conversion followed by adding the recording as in-progress in the retention manager.
In addInProgressRecording : We evaluate the available space needed for recording. if there is no more space available as mentioned in the above thread and the stack is unable to free any further space. The stack changes the Recording state to IN_PROGRESS_INSUFFICIENT_SPACE_STATE and will notify the application. After this notification thread is created :
The background TSB thread tries to update the disc usage & where it finds that there is no further space to copy the next chunk of the TSB data to the recording volume. At this point MPE_DVR_EVT_OUT_OF_SPACE is fired and then the stack update the recording state to IN_PROGRESS_WITH_ERROR_STATE and notifies the application . PSB for relevant logs:
Log Snippet :
15:38:29.033 INFO RI.Stack- 112023 [Thread-2] INFO recording.RecordingRetentionManager - Adding In Progress Recording: RecordingContentItemLocal
15:38:29.049 INFO RI.Stack- 112033 [Thread-2] INFO recording.RecordingRetentionManager - Attempting to free 48524124 bytes of purged recordings
15:38:29.049 DEBUG RI.Stack- 112034 [Thread-2] DEBUG recording.RecordingRetentionManager - Checking 0 recordings to purge
15:38:29.049 WARN RI.Stack- 112034 [Thread-2] WARN recording.RecordingRetentionManager - Freed 0 bytes. Unable to free sufficient space. Needed 48524124
15:38:29.049 DEBUG RI.Stack- 112035 [Thread-2] DEBUG recording.RecordingImpl - RI 0xcd3301cf: setStateAndNotify - oldState: PENDING_NO_CONFLICT_STATE New State: IN_PROGRESS_INSUFFICIENT_SPACE_STATE
15:38:29.065 DEBUG RI.Stack- 112057 [Thread-2] DEBUG recording.RecordingImpl - RI 0xcd3301cf: saveRecordingInfo: RecordingContentItemLocal
15:38:29.377 DEBUG RI.Stack- <<DVR>> sendVolumeAlarms - Current free space level is 1
15:38:29.377 WARN RI.Stack- <<DVR>> convert_event_cb - Device is full! Conversion session terminating! sess = 26008008, volume = 215DBB68, device = 0F94ED00
15:38:29.377 DEBUG RI.Stack- <<DVR>> notifyDvrQueue - queueID: 0xdd2c008, event: 0x1000
15:38:29.377 DEBUG RI.Stack- mpeos_threadCreate - td = 20E60230, mutex = 20e83538
15:38:29.408 DEBUG RI.Stack- <<DVR>> mpeos_dvrTsbConvertStop - TSB = 20ECEEF8
15:38:29.408 DEBUG RI.Stack- threadStart (thread ending) - td = 20E60230, mutex = 20e83538
15:38:29.439 DEBUG RI.Stack- 112428 [ED-Normal] DEBUG recording.RecordingImpl - RI 0xcd3301cf: RecordingImpl: Native recording termination event recieved //Here state will be set to IN_PROGRESS_WITH_ERROR_STATE and will notify application.


Issue : As per the DVR Spec OC-SP-OCAP-DVR-I05-090612: I.11 Use Case: the application expects IN_PROGRESS_WITH_ERROR_STATE(for SPACE_FULL) for the recording request when the disc is full, but actually it receives IN_PROGRESS_INSUFFICIENT_SPACE_STATE first followed by IN_PROGRESS_WITH_ERROR_STATE.

My Query :Is this behaviour acceptable ?

Joined: 2008-12-18

I would say there's nothing in the specification saying that transitioning from PENDING to IN_PROGRESS_INSUFFICIENT_SPACE to IN_PROGRESS_WITH_ERROR is disallowed when the space is full (or nearly full). There are certainly valid cases where this is going to happen and apps need to be prepared for this.
Note that Appendix I ("Recording Use Cases") is Informative (non-normative). So an implementation is not required or limited to implementing the exact behavior described in the use cases. The normative text from the spec and javadoc is the letter of the law.