summaryrefslogtreecommitdiff
path: root/README.vps
blob: d81f5d1a29f31afd6e461f81b1fc9fffcfa9c6ce (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
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")