mirror of
https://github.com/vdr-projects/vdr.git
synced 2025-03-01 10:50:46 +00:00
9384e56566
- Completed the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed some descriptor handling in 'libsi' (thanks to Stéphane Esté-Gracias). - Fixed handling the current menu item (thanks to Marc Hoppe). - Fixed assigning events to timers (they no longer get "stuck"). - Added log entries whenever the running status of an event changes (currently only logging the first 30 channels). - Fixed handling timers in VPS margin if the EPG scan is turned on (the EPG scan switched the device away from the channel, so it wouldn't see the change of the running status). - Fixed handling "itemized" texts in EPG data (thanks to Stéphane Esté-Gracias for pointing out this problem, and Marcel Wiesweg for improving 'libsi'). - Fixed handling VPS times at year boundaries. - Avoiding too many consecutive "ring buffer overflow" messages (which only slowed down performance even more). - Taking the Sid into account when detecting version changes in processing the PMT (thanks to Stéphane Esté-Gracias for pointing out this problem). - Completed the Russian OSD texts (thanks to Vyacheslav Dikonov). - Any newline characters in the 'description' of EPG events are now preserved to allow texts to be displayed the way the tv stations have formatted them. This was also necessary to better display itemized texts. - Fixed detecting the running status in case an empty EPG event is broadcast (thanks to Michael Pennewiß for pointing this out). - Improved performance when paging through very long menu lists. - Removed cSchedule::GetEventNumber() and cSchedule::NumEvents(). There is now cSchedule::Events() that returns the list of events directly. - Avoiding occasional bad responsiveness to user interaction caused by assigning events to timers. - Now explicitly turning on the LNB power at startup, because newer drivers don't do this any more (thanks to Oliver Endriss for pointing this out).
137 lines
6.2 KiB
Plaintext
137 lines
6.2 KiB
Plaintext
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")
|