frodovdr/vdr
1
0
Fork 0
mirror of https://github.com/vdr-projects/vdr.git synced 2025-03-01 10:50:46 +00:00
Code Issues Packages Projects Releases Wiki Activity
vdr/README.vps
Klaus Schmidinger 78e3da813c Version 1.3.39 
- The SVDRP command LSTT now accepts the new option 'id' to have the channels
  of the timers listed with their unique channel ids instead of their numbers
  (suggested by Matthias Schniedermeyer).
- Added a missing #include <linux/unistd.h> to thread.c (thanks to Ville Skyttä).
- Fixed the "plugins-clean" and "plugins-install" targets in the Makefile (thanks
  to Andreas Brachold).
- Fixed handling "more than 3 byte" key sequences in cKbdRemote::ReadKeySequence()
  (thanks to Peter Bieringer). If you are using the PC keyboard as remote control
  input you may need to make VDR newly learn the keys by removing the remote.conf
  file.
- To avoid problems with access rights when VDR shall run as 'root' it now skips
  all SetCaps() and SetUser() calls when it is started as 'root' and "-u root"
  is given.
- Added missing i18n entry for the "Timer" button (thanks to Ville Skyttä)
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Making the "Menu" key behave consistently has not been well received by several
  users, so the new option "Setup/OSD/Menu button closes" can be used to get the
  old behavior back (which also is the default value of this option).
- Dropped the default vdr user. The program now always runs under the user id
  it was started from, unless the '-u' option is given and it was started from
  the 'root' user. If you want to have a default vdr user, you can activate and
  adjust the "VDR_USER = vdr" line in your Make.config file (from the original
  patch by Ludwig Nussel).
- Key macros can now be defined for all non-modeless keys (suggested by Mirko Dölle).
- Adjusted the "KEY MACROS" section of vdr.5 to the new plugin calling mechanism
  introduced in version 1.3.32.
- Removed the now obsolete "ca.conf" section from vdr.1 (thanks to Ville Skyttä).
- Added missing description of L and R circular polarization to 'diseqc.conf'.
- Added a note about "modprobe capability" to INSTALL (suggested by Patrick Cernko).
- Fixed canonicalizing the file name in the SVDRP command GRAB to allow full path
  names (thanks to Stefan Huelswitt).
- Added a missing '-' to the example for viewing a grabbed image on a remote host
  (reported by Philippe Gramoullé).
- Made the "What's on now/next?" menus a lot faster by storing a pointer to each
  channel's schedule in the cChannel data.
- Made the log messages regarding lost lock of devices "info" instead of "error"
  (suggested by Andreas Brachold).
- The SVDRP command GRAB allows file names without extension again (suggested by
  Stefan Huelswitt).
- Pressing '0' in the "Schedule" menu now rotates through displaying "This event on
  this channel", "This event on all channels" and "All events on all channels".
  This can be used to find reruns of a given show, or the episodes of a series.
  Note that if there are many channels in your channels.conf, displaying the
  "All events on all channels" page may take a while.
- The status markers in the "Schedule" menu are now only updated if a submenu is
  closed in which a timer has been modified, which speeds up closing submenus.
- Now only writing Dolby Digital tracks into the 'info.vdr' file of a recording
  if Setup.UseDolbyDigital is true (suggested by André Weidemann).
- Added a leading '0' to the day in the DayDateTime() function (thanks to Rolf
  Ahrenberg).
- No longer displaying color buttons in the recording info menu if it has been
  invoked from a player (reported by Jürgen Schilling).
2006-01-15 18:00:00 +01:00

138 lines
6.3 KiB
Plaintext
Raw Blame History

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...
Contact:
--------
ARD Digital: http://www.ard-digital.de/home/index.php?id=16&languageid=1
ZDF vision: http://www.zdf.de/ZDFde/inhalt/1/0,1872,1021601,00.html (select "zdfvision")
phone: 06131/706754
Reference in New Issue View Git Blame Copy Permalink