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