Difference between revisions of "GetAllRecordingSchedules"

From Gvp-public
Jump to navigation Jump to search
 
(5 intermediate revisions by 2 users not shown)
Line 38: Line 38:
 
ParamName=state
 
ParamName=state
 
|ParamType=[[RecordingScheduleState|RecordingScheduleState]] enum
 
|ParamType=[[RecordingScheduleState|RecordingScheduleState]] enum
|ParamRequired=optional
+
|ParamRequired=Required
|ParamDescription=Recording schedule state to filter results
+
|ParamDescription=Recording schedule state to filter results. Status 0 "Undefined" is only valid in OP and returns all user's recordings regardless of its status. NOT working in Mediaroom
 
}}
 
}}
 
{{Api_Parameter|
 
{{Api_Parameter|
 
ParamName=targetDeviceId
 
ParamName=targetDeviceId
 
|ParamType=int
 
|ParamType=int
|ParamRequired=optional
+
|ParamRequired=required
 
|ParamDescription=Allows identifying the user's device (STB) on which the application will be applied, in the case that several DVR devices may exist in the household (does not apply to MiView and Mediaroom)
 
|ParamDescription=Allows identifying the user's device (STB) on which the application will be applied, in the case that several DVR devices may exist in the household (does not apply to MiView and Mediaroom)
 
}}
 
}}
Line 57: Line 57:
 
:    "Limit": 10,
 
:    "Limit": 10,
 
:    "Count": 48,
 
:    "Count": 48,
:    "Content":[ paginatedList of [[RecordingSchedule|RecordingSchedule]] objects ]
+
:    "List":[ paginatedList of [[RecordingSchedule|RecordingSchedule]] objects ]
 
}
 
}
  

Latest revision as of 14:36, 2 July 2019

Description

Get a list with all the Schedules (as a paginatedList of RecordingSchedule objects) for the current user with a given Recording State.

In the case of series/recurrent recording schedules, the method also returns the individual recordings (not only the recordingschedule/RecordingDefinition/"parent" recording), due to backwards compatibility reasons and because of client (Go app) requirements:

Client apps need to know the individual recordings in order to show them graphically to the user ("drawing"/marking all the precise episodes that will be recorded in a series recording, etc.). Recordings created as "series recording" are marked (as "series" type) and associated with the corresponding seriesId (and rest of relevant fields such as the scheduleId, programId, etc.)

It is possible to differentiate the recording "type" ("parent recording/definition" vs "child recording") through the "recordingHiearchy" and "ParentId" fields of the RecordingSchedule object


* MiViewTV comments:

  • Because of the "reutilisation" of programIds in "virtual channels", a programId could be repeated in different channels. This way, although ALU considers the concept of "recording (schedule) id" (with value equal to the programId), a programId is actually not enough to identify a precise recording, as it is also necessary to provide the channelId. This way, the real value that allows a unique identification of recording schedules in ALU is the combination of programId (or recording_id in the ALU model) + channelId (service_uid in the ALU terminology). This way, the id of the recording schedule returned to clients by UNIAPI (member "ID" of the object RecordingSchedule), in the case of MiView, will be a string concatenating the id (programId) with the service_uid (channel). eg: "4800508_3" (where 4800508 would be the recording id/programId returned by MiView and "3" would be the corresponding service_uid)

* Mirada comments:

  • Clients should store the lastModified parameter included in the RecordingSchedule object(s), as future invocations to cancel/delete recordings methods will require submitting the "lastModified" value in the request. When a client wants to request a cancel/delete, it will need first to retrieve the information (via GetAllRecordingSchedules).
  • In Mirada, when creating a "series recording schedule", UNIAPI only creates the "containter"/parent recording, and the STB will add all the associated episodes automatically (as a recording "Linked" to a parent recording). When retrieving the list of recordings from Mirada, "child" recordings will have a reference to their parent (series recording schedule), properly filled in the corresponding fields of the RecordingSchedule object.

Parameters

  • token (String, required)
A valid token for identifying the API session context and logged user.
  • offset (int, optional)
Index of the initial result of the list, begins with 0
  • limit (int, optional)
Quantity of results showed, with the maximum of 100
Recording schedule state to filter results. Status 0 "Undefined" is only valid in OP and returns all user's recordings regardless of its status. NOT working in Mediaroom
  • targetDeviceId (int, required)
Allows identifying the user's device (STB) on which the application will be applied, in the case that several DVR devices may exist in the household (does not apply to MiView and Mediaroom)


Returns

Returns a JSON object with a list of RecordingSchedule.

Example:

{

"Offset": 0,
"Limit": 10,
"Count": 48,
"List":[ paginatedList of RecordingSchedule objects ]

}


Exceptions

Possible error results (included in the GVP general error list) are:

  • 8 MissingRequiredParameter OpenPlatform, Mirada
  • 211 RecordingSubscriberNotFound OpenPlatform, MiViewTV, Mediaroom
  • 212 RecordingSubscriberNotSubscribed OpenPlatform, MiViewTV
  • 213 RecordingUnknownError OpenPlatform, MiViewTV, Mediaroom
  • 235 RequestedLanguagesUnavailable OpenPlatform, Mirada
  • 236 RecordingUpdatedFromAnotherDevice OpenPlatform, Mirada
  • 245 RecordingUnknownRecordingType OpenPlatform, Mediaroom
  • 246 RecordingUnknownPagingType OpenPlatform, Mediaroom


Caching

This method is not cached.


Known issues

None


Version history

API Version Number Change description Changes author
2.4 Initial method design
2.4 drop 1 Added support for Mirada and Mediaroom. Introduced new parameter targetDeviceId
7.1 Added support for OpenPlatform CPVR José Manuel Escartín


See also