Changes

Jump to navigation Jump to search
no edit summary
<p>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:</p>
<p>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.)</p>
 
<p>* '''MiViewTV comments''':</p>
* 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|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)
<p>* '''Mirada comments''':</p>
editor
278

edits

Navigation menu