2004-02-29 14:21:22 +01:00
|
|
|
|
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 "<22>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 "<22>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<6F>r?" runs until 21:15, they
|
|
|
|
|
|
switch the _next_ programme to running (which implicitly set "Wer wird
|
|
|
|
|
|
Million<6F>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...
|
2004-03-03 19:20:20 +01:00
|
|
|
|
|
|
|
|
|
|
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")
|
2006-01-09 22:06:52 +01:00
|
|
|
|
phone: 06131/706754
|
