VPS fallback patch

  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:
> 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.

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 Mon, 18 Jul 2011 12:53:45 +0100
Dave <vdr@pickles.me.uk> wrote:

> 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.

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:

> 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.

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 Monday 18 July 2011 13:09:19 Laz 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?

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.

> 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!

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:
> On Monday 18 July 2011 13:09:19 Laz 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?
> 
> 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.
> 
> > 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!
> 
> The TVAnytime patch includes this VPS Fallback patch, but you don't
> need the rest of it just to do accurate recording.

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 18.07.2011 13:53, Dave wrote:
> 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.

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