Implemented VPS controlled timers1.3.5

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...