Difference between revisions of "GetRecordingSchedule"

From Gvp-public
Jump to navigation Jump to search
Line 6: Line 6:
  
 
<p>* '''Mirada comments''':</p>
 
<p>* '''Mirada comments''':</p>
−
* Clients wanting to cancel (or delete) a recording should have to firstly request a [[GetAllRecordingSchedules|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.
+
* In the case of series/recurring recording schedules, a usual case is that the client requests info on the "parent"/container RecordingSchedule (in order to later cancel/delete the whole series definition, etc.). Please, notice that this [[RecordingSchedule|RecordingSchedule]] will be (in this case for series) just a "container" or parent definition, with no precise event (program, channel, time) info associated.
−
* When cancelling things "in the future" (not started yet), such as individual movies/episodes not started yet, or the cancellation of entire series, the final purpose is to "avoid" the future recording of an event. The [[RecordingSchedule|RecordingSchedule]] object would be set to GVP status "Cancelled"
+
* 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). In the case of series, Mirada method will return the "parent"/container recording that will not have associated "events" and all the recordings for the precise "events" associated to that "parent". "Child" recordings will have a reference to their parent (series recording schedule)  
−
* When cancelling only 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 recording (and the status of the schedule, in both Mirada's backend and in the [[RecordingSchedule|RecordingSchedule]] object returned to clients, would be set to "finished"​/completed, not "cancelled"). This is the case when cancelling individual events or episodes within series (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 a recording definition (the equivalent concept 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 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, the existing recordings are kept, but the recording definition's state is set to "cancelled," preventing any future recordings from being made. After all existing recordings have been deleted, the recording definition is automatically deleted.</li>
 
−
  <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, after all existing recordings have been deleted, the recording definition is automatically deleted.</li>
 
−
</ul>
 
−
* In the [[RecordingSchedule|RecordingSchedule]] object handled by GVP (returned to clients), the status would be set to the state "Cancelled" ​(as this state includes both "cancelled" and "deleted" schedules that will be the states managed by Mediaroom when invoking RemoveRecordingDefinition)
 
  
 
|Parameters=
 
|Parameters=

Revision as of 09:28, 31 October 2014

Description

Gets info on a specific recording schedule (returned as a RecordingSchedule object). The Id of the recording schedule to be retrieved is provided as an input parameter.

* 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:

  • In the case of series/recurring recording schedules, a usual case is that the client requests info on the "parent"/container RecordingSchedule (in order to later cancel/delete the whole series definition, etc.). Please, notice that this RecordingSchedule will be (in this case for series) just a "container" or parent definition, with no precise event (program, channel, time) info associated.
  • 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). In the case of series, Mirada method will return the "parent"/container recording that will not have associated "events" and all the recordings for the precise "events" associated to that "parent". "Child" recordings will have a reference to their parent (series recording schedule)

Parameters

  • token (String, required)
A valid token for identifying the API session context and logged user.
  • recordingScheduleId (string, required)
ID (string) of the Recording Schedule to retrieve info
  • targetDeviceId (int, optional)
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 RecordingSchedule object.

Example:

{

RecordingSchedule object

}


Exceptions

  • None.


Caching

This method is not cached.


Known issues

None


Version history

API Version Number Change description Changes author
2.4 drop 1 Initial method design (for MiView, Mirada and Mediaroom)


See also

Retrieved from "https://wikis.tid.es/gvp-public/index.php?title=GetRecordingSchedule&oldid=914"