Feature: Add GetRecordingCalendar / FindRecordingDays to Recording Search Service for optimized archive calendar retrieval

[Abay11]

Currently, the Recording Search Service Specification lacks a lightweight, synchronous method to retrieve a high-level overview of the days that actually contain recorded data.

To build a "Calendar" or "Timeline" view in a Client/VMS application, developers currently have two sub-optimal choices:

1. Use GetRecordingSummary, which only returns the absolute oldest (DataFrom) and newest (DataUntil) timestamps. It does not reveal any gaps in between (e.g., if a camera was offline for a week or configured for motion-only recording).
2. Initiate a full asynchronous search session using FindRecordings and iterate through results via GetRecordingSearchResults. This creates significant overhead for both the device (parsing all track slices/events) and the network, just to determine if a specific day has any data.

Proposed Solution

Introduce a new optional command to the Recording Search Service: GetRecordingCalendar (or FindRecordingDays).

This method should return a flat list of calendar dates (or discrete time ranges representing days) that contain recorded data within a requested time window. To ensure consistency with existing commands like GetRecordingSummary and FindRecordings, the API should use standard ONVIF data types and structures.

Proposed Interface Definition

1. Capability Addition

In SearchCapabilities, add a new optional parameter to indicate device support:

<xs:attribute name="RecordingCalendar" type="xs:boolean" default="false">
  <xs:annotation>
    <xs:documentation>Indicates support for the GetRecordingCalendar command.</xs:documentation>
  </xs:annotation>
</xs:attribute>

2. GetRecordingCalendar Request

The request allows filtering by a specific recording (optional) and defining the time boundaries.

<xs:element name="GetRecordingCalendar">
  <xs:complexType>
    <xs:sequence>
      <!-- Optional: limit search to a specific recording token -->
      <xs:element name="RecordingToken" type="tt:ReferenceToken" minOccurs="0"/>
      <!-- Mandatory: Time range to check -->
      <xs:element name="StartPoint" type="xs:dateTime"/>
      <xs:element name="EndPoint" type="xs:dateTime"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

3. GetRecordingCalendarResponse

The response returns an array of dates containing recorded data. To avoid timezone ambiguity, dates should be returned in xs:date (YYYY-MM-DD) format relative to UTC, or as a list of start-of-day timestamps:

<xs:element name="GetRecordingCalendarResponse">
  <xs:complexType>
    <xs:sequence>
      <!-- List of unique days containing data inside the requested range -->
      <xs:element name="RecordingDay" type="xs:date" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

Alternative Approach (Asynchronous Match)

If a synchronous response is deemed too heavy for low-end edge devices with large SD cards, this could follow the FindRecordings session pattern:

• FindRecordingCalendar(StartPoint, EndPoint) -> Returns a SearchToken.
• GetRecordingCalendarResults(SearchToken) -> Returns the list of xs:date items.

Impact

• Backward Compatibility: Fully backward compatible. Devices that do not support this feature will simply report RecordingCalendar="false" in their capabilities.
• Performance: Dramatically reduces VMS startup/sync times when generating historical calendars for edge storage (Profile G devices).

[ocampana-videotec]

@Abay11 is your organization member of ONVIF?

[ocampana-videotec]

@Abay11 , I am trying to reach out to you to understand your proposal and if you are a member of ONVIF, to determine how we can collaborate. Are you still interested in this idea? Thank you.