Description= Cancel each of the given RecordingSchedule and delete them from the platform.
Returns an rray array of [[RecordingSchedule|RecordingSchedule]] objects, filled with the recording related parameters. Clients wanting to cancel (or delete) a recording should have to firstly request a "GetAllRecordingSchedules" call, in order to retrieve the recordings ID and (in the case of Mirada) the associated lastModified value that must be included in the cancel/delete request. This parameter will not be available (GetAllRecordingSchedules will return 0) for some other rPVR backends. <p>* '''Mirada comments''':</p>* If Recordings from Go devices will be based on (GVP internal) scheduleID, but must be converted (by GVP gateway/UNIAPI) to the equivalent time frame (start time + duration) in order to be invoked to Mirada (as event-based recording is not possible without the mirada internal eventID). This will be done through a parameter in Mirada's create recording schedule was successfully cancelled method, indicating Mirada back-end that the provided time window must be converted to the associated internal event ID.* Mirada requires the identification of the "target" device (STB) affected by the method. GVP API allows two ways of selecting the "target device" for each method (this only applies to Mirada backend, as Mediaroom backend has an internal mechanism for managing the STBs associated to a subscriber and deleted only allows a "master" STB which performs all the PVR operations; so in Mediaroom it is not possible to select the target Device): Through the "targetDeviceId" parameter, or, if the "targetDeviceId" parameter is not sent by the platformclient, its state an automatic device selection will be used instead* In the case of "Canceledseries recording schedules"* If , the method will only create a given kind of "container recording schedule could not " where the actual recordings will be canceledadded. After creating the "container" (parent recording for the series), its state the STB will remain later (automatically and periodically, after detecting the parent recording schedule) add the recording for each episode linked to the series. <p>* '''Mediaroom comments''':</p>* Mediaroom service allows two types of recordings: Dynamic ("event-based") and "manual" (or "Scheduledtime-based"specifying channel ID, program, and time frame). GVP nPVR API only uses the Dynamic (event-based) mode, as the devices (such as Go) schedule recordings based on info from the EPG* If a given In principle, Mediaroom allows creation or recordings even when they are in conflict with other recording schedule was not found(s). In this case, its state it will be reflected it in the [[RecordingSchedule|RecordingSchedule]] struct of the response (using the boolean member "Not FoundConflicted"). Tt is also possible that some "conflicting" recordings are automatically detected and not registered by Mediaroom, so the process could result in an error (exception).
|Parameters=
|ParamRequired=optional (declared "optional" for backwards compatibility; but needed for correct operation)
|ParamDescription=ID (string) of the Recording Schedule to be canceled
}}
{{Api_Parameter|
ParamName=lastModified
|ParamType=int
|ParamRequired=optional (needed for correct operation in Mirada)
|ParamDescription=Date-time of last modification of the recording schedule (must be previously obtained from Mirada's backend)
}}
{{Api_Parameter|
{{!}}- valign="top"
! 2.4 drop 1
{{!}} Added support for Mirada and Mediaroom. Introduced new parameters recordingScheduleId , lastModified and targetDeviceId
{{!}}
{{!}}}