Changes

Jump to navigation Jump to search
1,769 bytes removed ,  09:28, 31 October 2014
no edit summary
<p>* '''Mirada comments''':</p>
* Clients wanting to cancel (or delete) a In the case of series/recurring recording should have to firstly request schedules, a [[GetAllRecordingSchedules|GetAllRecordingSchedules]] call, in order to retrieve the recordings ID and (in the usual case of Mirada) is that the associated lastModified value that must be included in client requests info on the cancel"parent"/delete request. ​This parameter will not be available container RecordingSchedule (GetAllRecordingSchedules will return 0) for some other rPVR backends.* When cancelling things "in the future" (not started yet), such as individual moviesorder to later cancel/episodes not started yet, or delete the cancellation of entire whole seriesdefinition, the final purpose is to "avoid" the future recording of an eventetc.). The Please, notice that this [[RecordingSchedule|RecordingSchedule]] object would will be set to GVP status (in this case for series) just a "Cancelledcontainer"or parent definition, with no precise event (program, channel, time) info associated. * When cancelling only In Mirada, when creating a thing that is just being recorded at the current moment (at the moment of invoking cancel by the client) the final purpose is to "stop" the ongoing series recording (and the status of the schedule", in both Mirada's backend and in UNIAPI only creates the [[RecordingSchedule|RecordingSchedule]] object returned to clients, would be set to "finishedcontainter"/completedparent recording, not "cancelled"). This is and the STB will add all the case when cancelling individual events or associated episodes within series automatically (but NOT cancelling the whole series) AND the event to cancel is just being recorded at this moment. <p>* '''Mediaroom comments''':</p>* The Mediaroom API (RemoveRecordingDefinition) method removes as a recording definition (the equivalent concept "Linked" to a [[RecordingSchedule|RecordingSchedule]]), and all associated upcoming recordings, from an account's schedule.​ The behavior of the method depends on whether there are recordings already associated with this parent recording definition:<ul> <li>If there are no recordings associated with this definition (there are no matching programs in the current EPG data), the recording definition is deleted.</li> <li>If recordings have already been made, In the existing recordings are keptcase of series, but Mirada method will return the recording definition's state is set to "cancelled,parent" preventing any future recordings from being made. After all existing recordings have been deleted, the recording definition is automatically deleted.</li> <li>If a container recording is currently in progress, it is halted. The recording definition's state is also set to that will not have associated "cancelled,events" preventing future recordings from being made. Again, after and all existing the recordings have been deleted, the recording definition is automatically deleted.</li></ul>* In the [[RecordingSchedule|RecordingSchedule]] object handled by GVP (returned to clients), for the status would be set to the state precise "Cancelledevents" ​(as this state includes both associated to that "cancelledparent" and . "deletedChild" schedules that recordings will be the states managed by Mediaroom when invoking RemoveRecordingDefinitionhave a reference to their parent (series recording schedule)
|Parameters=
editor
278

edits

Navigation menu