For some time (at least since 2008) Mandriva Linux have been including the attached patch in the version of vdr shipped with their distribution. It allows timers to be triggered directly by the Now/Next data in the EIT provided that a new parameter is set in the config file.
Looking back in the mailing list archives I see the question of including this feature in vdr is an old one; see for example:
http://www.linuxtv.org/pipermail/vdr/2005-August/003975.html
However I wonder if the time is now right to reconsider? In the UK an accurate Now & Next EIT is provided on DVB-T as part of the Freeview Plus (aka TV- Anytime) service, with the data being directly derived from the broadcasters' playout systems. I have been running vdr with this patch for two years and have never missed a recording due to incorrect information. It was really useful during the recent Wimbledon tournament when many programmes ran late due to live coverage of the tennis.
Dave
On Monday 18 Jul 2011, Dave wrote:
I will have to give your patch a go becuase I've recently missed a few recordings due to tennis and football over-running!!
I presume I need to set timers with no margin at the start and with vps enabled for all for this to work?
Do I also need your tvanytime patch for this to work? I did try it a few days back with vdr-1.7.19 but I kept on gettign seg faults from calls to strcpyrealloc! I was, however, in the process of sorting out some other issues at the time so will have to try it again now that I've fixed the other problems!
:-)
Cheers,
Laz
On Monday 18 July 2011 13:09:19 Laz wrote:
In your setup.conf you should have:
UseVps = 1 VpsFallback = 1 VpsMargin = 120
The last one sets the number of seconds before the scheduled start time that VDR begins monitoring the p/f table for the event start.
Also whenever you set a new timer you need to set the 'flag' field to 5 - if using vdradmin-am tick the 'use VPS' box in the New Timer window - as well as setting the start time with no margin.
The TVAnytime patch includes this VPS Fallback patch, but you don't need the rest of it just to do accurate recording.
Dave
On Monday 18 Jul 2011, Dave wrote:
All looks good. Your small patch works but your TVAnytime patch causes me lots of segmentation faults! This is with vdr-1.7.19 having already been patched with the liemikuutio patch (I don't think it touches anything likely to affect this).
An example:
*** glibc detected *** /home/laz/dvb/vdr-1.7.19/vdr: malloc(): memory corruption: 0xb64a81b8 ***
gdb backtrace:
(gdb) bt #0 0xffffe424 in __kernel_vsyscall () #1 0xb7c5f911 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7c62d42 in abort () at abort.c:92 #3 0xb7c959d5 in __libc_message (do_abort=2, fmt=0xb7d6aa70 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb7c9fac1 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0xb696b780) at malloc.c:6283 #5 0xb7ca28a4 in _int_malloc (av=<value optimized out>, bytes=<value optimized out>) at malloc.c:4396 #6 0xb7ca44ac in __libc_malloc (bytes=14) at malloc.c:3660 #7 0x0813c006 in strcpyrealloc (dest=0x0, src=0xb737fc44 "The Good Wife") at tools.c:117 #8 0x080d0adb in cEvent::SetTitle (this=0xb6485f00, Title=0xb737fc44 "The Good Wife") at epg.c:185 #9 0x080cda8a in cEIT::cEIT (this=0xb738022c, Schedules=0x81993e0, Source=1409286144, Tid=96 '`', Data=0xb7380338 "`\364@ \372\315 \370 \031#: aw;\331\320\022\065", OnlyRunningStatus=false) at eit.c:297 #10 0x080ce302 in cEitFilter::Process (this=0xb6443f20, Pid=638, Tid=44 ',', Data=0xb7380338 "`\364@ \372\315 \370 \031#: aw;\331\320\022\065", Length=1091) at eit.c:403 #11 0x0811e9bb in cSectionHandler::Action (this=0xb6444098) at sections.c:212 #12 0x08135ee5 in cThread::StartThread (Thread=0xb6444098) at thread.c:257 #13 0xb7fa0c39 in start_thread (arg=0xb7381b70) at pthread_create.c:304 #14 0xb7d0193e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(The only plugin loaded here is streamdev-server to give me a dummy output device.)
The SEGV isn't always in the same place: I did originally think it was only when strcpyrealloc is called from cEvent::SetSeriesCRID but it seems to be from any call to strcpyrealloc at random. I've also seen it SEGV after calls to qsort.
I'm a bit suspicious about the SEGV happening at a different place each time I run it. I suspected bad RAM and I did try running Memtest86+ last week but got no errors after a few mins run (when I've had RAM die in the past, it's always shown up pretty quickly in a Memtest86 run). I don't think it's two threads trying to use the same pointer but I could be wrong!
Any thoughts?
I think I'll just stick with the VPS Fallback stuff for now!
Cheers,
Laz
On Mon, 18 Jul 2011 12:53:45 +0100 Dave vdr@pickles.me.uk wrote:
Does the standard EIT now reflect the actual times? I was under the impression that the EIT still reflected the original schedule and the actual times were somewhere in the TVAnytime extensions.
On Monday 18 July 2011 13:58:55 Tony Houghton wrote:
For the UK Freeview+ service, the EIT p/f table is used as the accurate recording information, and the start of a programme is signalled by the event_id appearing in the 'present' event. The alternative (preferred by ETSI TS 102 323) is a TVA_id descriptor (0x75) in the p/f table, but these don't seem to be broadcast in the UK.
Dave
On 18.07.2011 13:53, Dave wrote:
VDR interprets the PDC (Programme Delivery Control) descriptor in order to correctly record broadcasts that run longer or are shifted. If a channel doesn't provide a PDC descriptor, it's usually not reliable to use the "running status" as an indicator for the beginning/end of a broadcast.
So, if a station actually wants to provide correct information on when a broadcast begins/ends, the PDC descriptor is the way to go.
Klaus
-
Dave -
Klaus Schmidinger -
Laz -
Tony Houghton