Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-13-10: ScheduledRecording — Recording Scheduler Service
UPnP ScheduledRecording — Part 13-10: Scheduled Recording Device and Control Point
ISO/IEC 29341-13-10 specifies the ScheduledRecording service architecture for UPnP networks, providing a standardized framework for scheduling, managing, and executing media content recordings on networked recording devices. This standard is essential for modern digital video recorder (DVR) and personal video recorder (PVR) systems that operate in multi-device home network environments, enabling users to schedule recordings from any control point on the network and have them executed by any capable recording device.
The true value of 29341-13-10 lies in its device-agnostic scheduling model: a control point in the living room can schedule a recording on a tuner located in the basement, as long as both implement the ScheduledRecording service correctly.
Recording Schedule Management and Conflict Resolution
The core of the ScheduledRecording service is the Schedule resource, represented as a state variable containing a list of scheduled recording entries. Each entry specifies the source channel or program identifier, the start time and duration, the recording quality profile, and the target storage location. The service exposes actions such as AddSchedule, DeleteSchedule, GetScheduleList, and UpdateSchedule to manage these entries.
One of the most practically important features of 29341-13-10 is its conflict resolution mechanism. When a new recording request overlaps with an existing scheduled recording that requires the same tuner resource, the service must determine whether the conflict can be resolved. Resolution strategies include prioritizing recordings based on user-assigned priority levels, suggesting alternative time slots, or alerting the user to resolve the conflict manually. The standard defines a ConflictEntry data structure that encodes the details of overlapping schedules, enabling control points to present clear conflict information to end users.
| Action | Purpose | Conflict Behavior |
|---|---|---|
| AddSchedule | Create a new recording schedule entry | Returns conflict error if resources are unavailable |
| UpdateSchedule | Modify an existing schedule entry | Re-evaluates conflicts with existing schedules |
| DeleteSchedule | Remove a schedule entry | May free resources for pending schedules |
| GetConflicts | Retrieve current conflict information | Returns list of ConflictEntry structures |
| SetResourceAllocation | Assign tuner or storage resources | Enables manual override of automatic allocation |
Conflict resolution logic must account for padding time before and after scheduled recordings. A common engineering oversight is assuming recordings are back-to-back, when in practice users often add pre-roll and post-roll padding that extends the effective resource reservation window.
Resource Management and Tuner Allocation
The ScheduledRecording service maintains a model of the recording device’s physical and logical resources, including tuners, transcoders, and storage volumes. Each resource is described by a set of capabilities — for example, a tuner’s supported modulation formats, a transcoder’s available output profiles, or a storage volume’s free space and maximum write rate.
Resource allocation follows a two-phase protocol. In the reservation phase, the service checks whether sufficient resources are available for the requested recording and tentatively reserves them. In the commitment phase, which occurs at or near the recording start time, the reservation is converted into a binding allocation. This two-phase approach allows the scheduler to handle last-minute changes — such as program schedule shifts or user cancellations — without wasting resource reservations.
A well-designed two-phase resource allocator can improve recording success rates by 15-25% compared to a naive single-phase approach, particularly in environments with time-shifted programming or frequent schedule changes.
Engineering Design Insights for ScheduledRecording
Implementing a robust ScheduledRecording service requires careful attention to several engineering details. Persistent storage of schedule entries is critical — the recording device must retain schedule information across power cycles and network disruptions. The standard recommends using non-volatile memory with atomic write operations to prevent schedule corruption during power loss.
Time zone and daylight saving time handling is another surprisingly complex aspect. Recording schedules often span DST transition periods, and the standard specifies that all schedule times should be stored in UTC with the local time zone offset recorded as metadata. This allows correct schedule interpretation regardless of changes to local time zone rules or the device’s physical location.
Finally, the standard defines a recording notification mechanism that alerts control points when scheduled recordings start, complete, or encounter errors. These notifications are delivered through the standard UPnP eventing mechanism, and control points can subscribe to receive status updates for specific schedules or for all schedules on a device.
Never assume that a scheduled recording will complete successfully. Implement comprehensive error monitoring and retry logic. Common failure modes include insufficient storage space, signal loss, encoding errors, and resource conflicts from unscheduled recordings initiated by other control points.
Frequently Asked Questions
Q: Can a ScheduledRecording device support multiple simultaneous recordings?
A: Yes, if the device has multiple tuners or supports channel bonding. The number of simultaneous recordings is limited only by the available tuner and transcoder resources. The AddSchedule action returns an error if insufficient resources exist.
A: Yes, if the device has multiple tuners or supports channel bonding. The number of simultaneous recordings is limited only by the available tuner and transcoder resources. The AddSchedule action returns an error if insufficient resources exist.
Q: How does the service handle overlapping recording requests for the same program?
A: The standard allows deduplication detection — if two schedules reference the same program identifier and quality profile, the service can merge them into a single recording with multiple storage references, conserving tuner resources.
A: The standard allows deduplication detection — if two schedules reference the same program identifier and quality profile, the service can merge them into a single recording with multiple storage references, conserving tuner resources.
Q: What happens if storage space runs out during a recording?
A: The service should generate a storage warning well before space is exhausted. If recording fails due to insufficient space, the partial recording should be preserved with metadata indicating its incomplete status, allowing the user to decide whether to keep or discard it.
A: The service should generate a storage warning well before space is exhausted. If recording fails due to insufficient space, the partial recording should be preserved with metadata indicating its incomplete status, allowing the user to decide whether to keep or discard it.
