Skip to main content

Questions about SI Database access and DVR Recording Manager

3 replies [Last post]
Joined: 2009-05-06

Recent changes were made to optimize access to the SI database.

DVR manager internally needs access to SI data base at start-up (i.e to reconstruct RecordingSpecs and get the list of recordings).

In the current implementation DVR waits for SI acquisition to complete (or to time out), before attempting access to the SI database.

My questions are:

1. With the IT-136 fix, does DVR recording manager still need to wait for complete acquisition or can it access the SI database immediately (and retry if request fails).

2. This is more DVR question: my understanding is that recording manager needs access to SIDB, for resolving locator in the recording meta data. What happens if current SI data no longer match the recording meta data.

For example an in progress (interrupted) recording can no longer be resumed because locator can not be resolved. Would that recording be transitioned to incomplete, or some other final state?

What happened to recording PID information, would these be resolved at the time recording is restarted (i.e remap the PIDs if necessary?).


Reply viewing options

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

Hey Amir,

Currently RecordingManager does depend upon the ability to resolve Locators when re-instantiating the RecordingRequests at startup. And while this could be removed, (a) since the recording initialization is done on 1 thread, any single unresolvable Locator will hold up the DB initialization, and (b) enumeration functions will still have to block until all RecordingRequests are loaded.

The issue behind both the recording database SI initialization and the playback of RecordedServices based on currently-unresolvable Locators is that RecodingManager currently depends upon being able to successfully resolve RecordingSpec fields (Locators, Broadcast Services) at arbitrary times.

RecordingManager should only resolve Locators (at least non-transport-dependant Locators) and Broadcast Service references at the time - and only at the time - the recording process starts or resumes (see OCORI-800). Once this issue is addressed, the loading of the Recording Database and the playback of RecordedServices will not depend upon the SIDB.

Note that the RecordingManager will still need to load the recording DB asynchronously (with the application's access to the DB blocked) since the load process may still take some time (e.g. due to serialization overhead and the need to synchronize the HN SRS).

As part of the fix for OCORI-800, when RecordingManager fails to resolve a Locator at recording start time - and its priority is RECORD_WITH_CONFLICTS - it should go into IN_PROGRESS_WITH_ERROR state with reason SERVICE_UNAVAILABLE.

I'm not sure I understand your last question about PID information.

Joined: 2009-05-06

Hi Craig,

Thanks for your answer. I guess I have a more generic question regarding how the stack is currently handling RecordingRequests at start-up.

In some cases the RecordingSpec may not match the current channel map information. For example sourceID is different. In that case how does RecordingManager resolve the Locators. Or is this
not an issue, because stored Recording Spec are based on FPQ?

In that context, what happens to recording specs that were in_progress and recordings that were not yet started?

I guess my question regarding PID was more about what metadata are used to represent the RecordingSpec in the RI. It's been quite a while since I looked at that, and probably my knowledge is out-dated.
Are recording PIDs stored at the time recording happens? If so, I am assuming this will result in segmented recording with each segment carrying its own metadata and recorded PID info.


Joined: 2008-12-18

On re-reading my reply, I realized that I mis-stated one thing: When I said that "Currently RecordingManager does depend upon the ability to resolve Locators when re-instantiating the RecordingRequests at startup. And while this could be removed, ..." what I meant is that "while the existing explicit SI block could be removed, ...". As I went on to describe, removing the need to resolve Locators at initialization really makes the situation moot.

Anyway, when you say "the sourceId is different", I presume you mean "when the sourceId *mapping* is different", correct? There's nothing in the I05 spec that states when the Locator is resolved to a transport-dependant Locator. However, to meet the requirements of SPI (SDV), it's necessary for the stack to follow changes in SourceID mappings when the recording enters or is in any IN_PROGRESS state. And it follows that the same should be true for standard Broadcast Services as well.

e.g. if a RecordingRequest is IN_PROGRESS, the stb is rebooted, and the RR's end time is still valid, the original RecordingSpec's Service/Locator is re-resolved at that time to the currently-mapped value. (and the same would be true for any recording interruption)

What should also be the case (but isn't today) is that the RecordedService returned from RR.getService() should be play-able regardless of the ability to resolve the RecordingSpec's Service/Locator. This will be solved when OCORI-800 is fixed (along with the other issues).

Regarding the PIDs, the PIDs/elementary stream types stored in the recording metadata are those returned from the platform in the PIDMapTable/mpe_DvrPidInfo. Each segment has its own list of recorded pids. These are allowed to change inter-segment as well - not just at the time the segment starts.