diff options
author | Klaus Schmidinger <kls (at) cadsoft (dot) de> | 2006-04-23 18:00:00 +0200 |
---|---|---|
committer | Klaus Schmidinger <kls (at) cadsoft (dot) de> | 2006-04-23 18:00:00 +0200 |
commit | 880c3ddb94c09d6cca411363ed6f981d4e150fd2 (patch) | |
tree | c7f88180032f51938367727f145928528406c0c4 /README.vps | |
parent | 293ed4027ed3c3c8fd6ef1e8bdd79bfe69193957 (diff) | |
download | vdr-patch-lnbsharing-880c3ddb94c09d6cca411363ed6f981d4e150fd2.tar.gz vdr-patch-lnbsharing-880c3ddb94c09d6cca411363ed6f981d4e150fd2.tar.bz2 |
Version 1.3.48vdr-1.3.48
- Updated the GPL copies (thanks to Ville Skyttä).
- Fixed several spelling errors (thanks to Ville Skyttä).
- Updated the Polish OSD texts (thanks to Jaroslaw Swierczynski).
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Updated the French OSD texts (thanks to Pierre Briec).
- Updated the Estonian OSD texts (thanks to Arthur Konovalov).
- Updated the Romanian OSD texts (thanks to Lucian Muresan).
- Updated the Danish OSD texts (thanks to Mogens Elneff).
- Updated the Russian OSD texts (thanks to Oleg Roitburd).
- Updated the Slovenian OSD texts (thanks to Matjaz Thaler).
- Fixed wrong credits for the patch that was used to implement cPlugin::Active().
- Simplified the 'grep|awk|sed' command to retrieve the VDR/APIVERSION to a single
'sed' call.
- Updated the Swedish OSD texts (thanks to Tomas Prybil).
- Modified the German OSD texts to be "less technical" (thanks to Andreas Brachold).
- Extended the version number reported with the '-V' option to also show the
current APIVERSION (suggested by Thomas Günther).
- Fixed handling empty titles in cEvent::FixEpgBugs() (reported by Rolf Ahrenberg).
- Fixed some missing '-' in the German OSD texts (thanks to Walter Koch).
- Added an error message about plugins that don't honor APIVERSION in their Makefile
(based on a suggestion by Udo Richter).
- Fixed a format string in recording.c to avoid a compiler warning on 64bit systems
(thanks to Christian Wieninger for reporting, and Werner Schweer for pointing out
that the 'z' modifier should be used here).
- Ignoring k_Repeat when deciding whether the same key has been pressed in string
input fields (based on a patch from Marko Mäkelä).
Diffstat (limited to 'README.vps')
-rw-r--r-- | README.vps | 137 |
1 files changed, 0 insertions, 137 deletions
diff --git a/README.vps b/README.vps deleted file mode 100644 index ee8909e..0000000 --- a/README.vps +++ /dev/null @@ -1,137 +0,0 @@ -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 |