Version 1.3.5vdr-1.3.5

- Fixed reading the EPG preferred language parameter from 'setup.conf'.
- Fixed switching to a visible programme in case the current channel has neither
  a video nor an audio PID.
- Fixed editing channels (SID now range checked) and creating new channels (NID,
  TID and RID are now set to 0).
- Fixed transponder handling to make it work with satellites that provide two
  transponders on the same frequency, with different polarization, like Hispasat
  at S30.0W (thanks to Thomas Bergwinkl for pointing this out). See man vdr(5)
  for details about the enhanced channel ID format.
- Since there appears to be no general solution for the UPT error yet, a recording
  now initiates an "emergency exit" if the number of UPT errors during one
  recording exceeds 10 (suggested by Gregoire Favre). Since the UPT error doesn't
  happen on my system, this has not been explicitly tested.
  The "preliminary fix" for the UPT error in VDR/dvbdevice.c has been disabled
  by default, since it makes channel switching unpleasently slow. If you want
  to have that workaround back, you can uncomment the line
  //#define WAIT_FOR_LOCK_AFTER_TUNING 1
  in VDR/dvbdevice.c.
- Adapted the 'sky' plugin to use the actual channel IDs, and to fetch EPG data
  from www.bleb.org.
- Limited automatic retuning to devices that actually provide the transponder
  (necessary for the 'sky' plugin).
- Fixed handling receivers in the 'sky' plugin, so that a recording on the same
  channel won't interrupt an ongoing Transfer Mode.
- Added subtable ID and TSDT handling to 'libsi' (thanks to Marcel Wiesweg).
- Fixed some Russian OSD texts (thanks to Vyacheslav Dikonov).
- Added the 'running status' to the EPG events. This is necessary for implementing
  the VPS function for recording.
- Removed the obsolete 'present' and 'following' handling from the EPG data.
- The EPG data is now always kept sorted chronologically in the internal data
  structures. This also means that any EPG data retrieved through the SVRDP
  command LSTE is guaranteed to be sorted by start time.
- Now using the 'running status' in the channel display, so that a programme
  that has an end time that is before the current time, but is still running,
  will still be shown in the display (provided the broadcasters handle the
  'running status' flag correctly). This also applies to programmes that have
  a start time that is in the future, but are already running.
- Implemented an "EPG linger time", which can be set to have older EPG information
  still displayed in the "Schedule" menu (thanks to Jaakko Hyvätti).
- Added PDCDescriptor handling to 'libsi'.
- Implemented handling the VPS timestamps (aka "Programme Identification Label")
  for full VPS support for timers (provided the tv stations actually broadcast
  this information). The VPS time is displayed in the event info page if it exists
  and is different than the event's start time.
- Extended the SVDRP command LSTE to allow limiting the listed data to a given
  channel, the present or following events, or events at a given time (thanks to
  Thomas Heiligenmann).
- Fixed a typo in libsi/si.h (thanks to Stéphane Esté-Gracias).
- Timers can now be set to use the VPS information to control recording a programme.
  The new setup options "Recording/Use VPS" and "Recording/VPS margin", as well as
  the "VPS" option in the individual timers, can be used to control this feature
  (see MANUAL for details).
  Note that this feature will certainly need a lot of testing before it can be
  called "safe"!
- The "Schedule" and "What's on now/next?" menus now have an additional column
  which displays information on whether there is a timer defined for an event,
  whether an event has a VPS time that's different than its start time, and
  whether an event is currently running (see MANUAL under "The "Schedule" Menu"
  for details).

1 files changed, 130 insertions, 0 deletions

diff --git a/README.vps b/README.vps
new file mode 100644
index 0000000..2aa19ce
--- /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...