Changes

* Recordings from Go devices will be based on Clients wanting to cancel (GVP internalor delete) scheduleIDa recording should have to firstly request a [[GetAllRecordingSchedules|GetAllRecordingSchedules]] call, but must be converted (by GVP gateway/UNIAPI) in order to retrieve the equivalent time frame recordings ID and (start time + duration) in order to be invoked to the case of Mirada (as event-based recording is not possible without ) the mirada internal eventID). This will associated lastModified value that must be done through a parameter included in Mirada's create recording method, indicating Mirada back-end that the provided time window must cancel/delete request. ​This parameter will not be converted to the associated internal event IDavailable (GetAllRecordingSchedules will return 0) for some other rPVR backends.* Mirada requires the identification of When cancelling things "in the future"target" device (STBnot started yet) affected by , such as individual movies/episodes not started yet, or the method. GVP API allows two ways cancellation of selecting entire series, the final purpose is to "target deviceavoid" for each method (this only applies to Mirada backend, as Mediaroom backend has the future recording of an internal mechanism for managing the STBs associated event. The [[RecordingSchedule|RecordingSchedule]] object would be set to a subscriber and GVP status "Cancelled"* When cancelling only allows a "master" STB which performs all thing that is just being recorded at the current moment (at the PVR operations; so in Mediaroom it is not possible to select moment of invoking cancel by the target Deviceclient): Through the final purpose is to "targetDeviceIdstop" parameterthe ongoing recording (and the status of the schedule, or, if in both Mirada's backend and in the "targetDeviceId" parameter is not sent by the client[[RecordingSchedule|RecordingSchedule]] object returned to clients, an automatic device selection will would be used instead* In the case of set to "series recording schedulesfinished"​/completed, the method will only create a kind of not "container recording schedulecancelled" where the actual recordings will be added). After creating This is the "container" case when cancelling individual events or episodes within series (parent recording for but NOT cancelling the whole series), AND the STB will later (automatically and periodically, after detecting the parent recording schedule) add the recording for each episode linked event to the seriescancel is just being recorded at this moment.

* The Mediaroom service allows two types of recordings: Dynamic API ("event-based"RemoveRecordingDefinition) and "manual" method removes a recording definition (or "time-based" specifying channel IDthe equivalent concept to a [[RecordingSchedule|RecordingSchedule]]), programand all associated upcoming recordings, and time frame)from an account's schedule. GVP nPVR API only uses ​ The behavior of the Dynamic method depends on whether there are recordings already associated with this recording definition:<ul> <li>If there are no recordings associated with this definition (event-basedthere are no matching programs in the current EPG data) mode, as the devices (such as Go) schedule recording definition is deleted.</li> <li>If recordings have already been made, the existing recordings are kept, but the recording definition's state is set to "cancelled," preventing any future recordings based on info from being made. After all existing recordings have been deleted, the EPGrecording definition is automatically deleted.</li>* In principle <li>If a recording is currently in progress, it is halted. The recording definition's state is also set to "cancelled," preventing future recordings from being made. Again, Mediaroom allows creation or after all existing recordings even when they are in conflict with other have been deleted, the recording(s)definition is automatically deleted. </li></ul>* In this case, it will be reflected it in the [[RecordingSchedule|RecordingSchedule]] struct of object handled by GVP (returned to clients), the response (using status would be set to the boolean member state "ConflictedCancelled").​​ Tt is also possible that some ​(as this state includes both "conflictingcancelled" recordings are automatically detected and not registered "deleted" schedules that will be the states managed by Mediaroom, so the process could result in an error (exceptionwhen invoking RemoveRecordingDefinition).