diff options
Diffstat (limited to 'README.vps')
| -rw-r--r-- | README.vps | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/README.vps b/README.vps new file mode 100644 index 00000000..2aa19ce8 --- /dev/null +++ b/README.vps @@ -0,0 +1,130 @@ +VPS (Video Programming Service) +=============================== + +Beginning with version 1.3.5 VDR supports the VPS method +of identifying programmes to record, and making sure they +are recorded in full length, even if they run longer than +initially specified or are shifted in time. + +Of course, the main prerequisite for this to work is that +the broadcasters actually provide the necessary data. In +particular these are + +- EPG data (well, obviously) +- the data for each event must contain the "Programme Identification Label" + descriptor, which contains the VPS timestamp for this programme +- the event data must provide and maintain the "Running Status" flag, + which indicates whether this programme is currently running or not. + +Currently only the German "Öffentlich Rechtliche" tv stations provide +the necessary VPS data, so this will work only for stations like "Das Erste", +"ZDF" and the like. + +Following is a step by step description of what happens for a VPS controlled +timer recording. First let's take a look at what the VDR user needs to do. + +VPS as seen by the VDR user: +---------------------------- + +When the VDR user sets up a timer that shall be under VPS control, there +are only two things that need to be done: + +1. Set the "Start" time to the actual VPS time as published in tv magazines. + Typically the VPS time is the same as the printed start time, unless + expliciltly specified otherwise. For instance, a tv magazine might print + + 20:15 Wetten, dass...? + (VPS = 20:14) + + In this case the timer would need to be set to 20:14. + +2. Set the "VPS" flag in the timer definition to "yes" in order to tell VDR + that this timer is to be handled under VPS control. This is no different + to old analog video recorders, where each timer has also had a separate + VPS flag. + +If the user sets up a timer from the "Schedule" menu, things are even simpler. +If the setup option "Recording/Use VPS" is set to "yes", any timer that is +programmed from an event that has VPS information will automatically be set +up as a VPS timer. + +IMPORTANT: In order for a recording to work under VPS control it is of +========== paramount importance that the start time is set to the actual + VPS time of that event, NOT some time a few minutes before the + event starts! If a timer is set to use VPS, and the time doesn't + match any event's VPS time, nothing will be recorded! + +VPS as seen by VDR: +------------------- + +The following things happen when VDR processes timers: + +- VDR regularly scans the EPG data and assigns events to the timers (see + cTimers::SetEvents() in VDR/timers.c). + This can be seen in the log file as + + timer 1 (15 1830-1900 'Neues') set to event 28.02.2004 18:30-18:59 (VPS: 28.02 18:30) 'neues' + +- When a VPS timer is asked whether it matches (i.e. whether a recording shall + be started), it checks whether it has an event assigned to it, and whether + that event has a running status of "starts in a few seconds" or "running" + (see cTimer::Matches(time_t t, bool Directly) in VDR/timers.c). This allows + the recording process to catch the entire programme, even if it runs longer + than initially advertised. It also works if it runs shorter or gets shifted. + +- When a VPS timer event is coming up (i.e. there are only a few minutes until + it starts, according to the related event data's start time - which may be + different than the VPS time!), VDR tunes a free DVB device to that transponder + (unless there is already a device tuned to that one) in order to make sure + that the event data (especially the "Running Status") will be up to date and + a change in the "Running status" flag will be seen immediately. This may + lead to the primary device being switched to a different channel if there + is no other free DVB device available. See the main program loop in VDR/vdr.c, + "Make sure VPS timers "see" their channel early enough:". + +Problems: +--------- + +- In order for a VPS controlled timer to function properly, it needs to "see" + any changes in the running status of its event. This means that one of the + DVB devices needs to be tuned to the proper transponder some time before + the actual start time of the event. However, this may result in an other + timer (with lower priority) to be stopped, because it occupies the DVB device + and has it tuned to a different transponder. + See "// Make sure VPS timers "see" their channel early enough:" in VDR/vdr.c. +TODO: + Something needs to be done to prevent two timers from repeatedly switching + the device between channels in such a situation. + +- If, for some reason, the driver doesn't deliver any more section data, a + VPS controlled timer will never see that the programme has started (or ended). +TODO: + Therefore some mechanism needs to be implemented that makes absolutely sure + we continuously receive at least the event data for the present event. + +Caveats: +-------- + +Apparently VPS in digital broadcasting is still in an early state. Only few +tv stations actually support it, and other tv stations don't even handle the +"Running Status" correctly (which, by itself, would already be helpful, even +without VPS). + +Here's a list of things that are apparently done wrong by the individual +stations: + +- The German "Öffentlich Rechtliche" tv stations, although supporting VPS, + don't switch the "Running Status" of an upcoming broadcast to "starts in + a few seconds", but rather go directly from "unknown" or "not running" to + "running". This may result in a recording that misses the first few seconds + of the programme. +- The RTL group handles EPG events in a rather random way. They change event + IDs randomly, and switch the "Running Status" flag at times that are only + losely related to the actual events. For instance, if the "RTL aktuell" + programme starts at 18:45, they switch that event to "running" at about + 18:43. Or, even worse, if "Wer wird Millionär?" runs until 21:15, they + switch the _next_ programme to running (which implicitly set "Wer wird + Millionär?" to "not running) at around 21:11 - so anybody using that + information to control recording would not see the end of that programme. + +... more following as it comes up... |