[vdr] Re: Buffer Overflows in vdr-1.3.13

[Gerald Raaf <Gerald.Raaf@allrun.de>]

Am Samstag, 23. Oktober 2004 18:31 schrieb C.Y.M:
> Klaus Schmidinger wrote:
> > Klaus Schmidinger wrote:
> >>Klaus Schmidinger wrote:
> >>>...
> >>>The problem we are facing at the moment is that the remuxer's result
> >>>buffer runs full and doesn't get emptied any more. Presumably this
> >>>happens because it can't get any sync on useful data, hence the
> >>>additional debug output.
> >>
> >>I believe I found what's causing the resultBuffer in cRemux to
> >>run full. This modification shoud fix it:
> >>
> >>--- remux.c     2004/10/16 09:11:52     1.19
> >>+++ remux.c     2004/10/23 11:53:51
> >>@@ -597,7 +597,7 @@
> >>                Count += l;
> >>                }
> >>             else
> >>-               resultSkipped = i;
> >>+               resultSkipped = i + ((l > 0) ? l : 0);
> >
> > Actually 'resultSkipped = i + l' should be ok, too, since 'l < 0' has
> > already been checked further above.
> >
> > Klaus
> >
> >>             if (l > 0)
> >>                i += l - 1; // the loop increments, too
> >>             }
> >>
> >>@C.Y.M: can you please test whether this fixes your problems with the
> >>        consecutive 1 minute timers? You should apply this patch to
> >>        the plain vanilla VDR 1.3.13 remux.c, without the workaround
> >>        that did "clearing resultBuffer before sync".
> >>
> >>Klaus
>
> So far, so good.. I have not been able to cause a buffer overflow with
> this new patch applied (plus removing the previous remux.c patch).
> Thanks!  I will post if I see anything.  I have also applied the changes
> to transfer.c as just mentioned in another thread (using 9/10 instead of
> 2/3).  These are the two fixes I am now using (nothing else):
>
> --- vdr-1.3.13/remux.c.original 2004-10-23 08:53:19.000000000 -0700
> +++ vdr-1.3.13/remux.c  2004-10-23 08:59:57.000000000 -0700
> @@ -597,7 +597,7 @@
>                  Count += l;
>                  }
>               else
> -               resultSkipped = i;
> +               resultSkipped = i + l;
>               if (l > 0)
>                  i += l - 1; // the loop increments, too
>               }
>
> AND
>
> --- vdr-1.3.13/transfer.c.orig  2004-10-20 12:21:23.000000000 -0700
> +++ vdr-1.3.13/transfer.c       2004-10-20 12:22:04.000000000 -0700
> @@ -65,7 +65,7 @@
>           int Count;
>           uchar *b = ringBuffer->Get(Count);
>           if (b) {
> -           if (Count > TRANSFERBUFSIZE * 2 / 3) {
> +           if (ringBuffer->Available() > TRANSFERBUFSIZE * 9 / 10) {
>                 // If the buffer runs full, we have no chance of ever
> catching up
>                 // since the data comes in at the same rate as it goes
> out (it's "live").
>                 // So let's clear the buffer instead of suffering from
> permanent

i can confirm this, but i use this patch for transfer.c but i think it's more 
or less the same.
--- vdr-1.3.13-orig/transfer.c  2004-10-16 11:22:58.000000000 +0200
+++ vdr-1.3.13/transfer.c       2004-10-20 13:21:40.778696440 +0200
@@ -65,7 +75,7 @@
          int Count;
          uchar *b = ringBuffer->Get(Count);
          if (b) {
-           if (Count > TRANSFERBUFSIZE * 2 / 3) {
+           if (ringBuffer->Available() > TRANSFERBUFSIZE * 2 / 3) {
                // If the buffer runs full, we have no chance of ever catching 
up
                // since the data comes in at the same rate as it goes out 
(it's "live").
                // So let's clear the buffer instead of suffering from 
permanent

And because i get the Locking Problem on (pc1) i also used
your patch (vdr-1.3.13-tunerlockfix.diff) from from [vdr] Fixed tuner lock 
detection thread.
I test this on two pc's:
pc1:
kernel 2.6.9
dvb-cvs from 23.10.2004
3 FF-Cards (1 Nexus-s and 2 revision 1.3 Cards)

pc2:
kernel 2.6.9
dvb-cvs from 23.10.2004
1 budget Card
matrox g550
and xine-0.5.2 plugin

tests i've done on both machines:
turn on epg-scan which always trigger an emergency restart when a record 
starts, but i have to wait for about half'n hour to get the lock problem on 
pc1.
made some timer recordings, after recording starts, a minute later start the 
next timer with higher priority, (on pc1 i first start three timers, all of 
them starts 1 minute later, so all cards are used).
And watch one Movie at Recording time.

All recordings are ok, with some pause for those which are interupted from 
recording with higher priority.