[vdr] Re: Buffer Overflows in vdr-1.3.13

["C.Y.M" <syphir@syphir.sytes.net>]

Klaus Schmidinger wrote:
> Chad Flynt wrote:
>
> > ...
> >
> > > > I tried this and actually was able to reproduce this.
> > > > Unfortunately it didn't happen any more since I have inserted
> > > > a few lines to test something. Will try that again tomorrow.
> > > >
> > > > If somebody would like to try this:
> > > >
> > > > --- remux.c     2004/10/16 09:11:52     1.19
> > > > +++ remux.c     2004/10/19 16:23:00
> > > > @@ -556,6 +556,11 @@
> > > >   int resultCount = 0;
> > > >   uchar *data = resultBuffer->Get(resultCount);
> > > >   if (data) {
> > > > +     if (!synced && resultCount > RESULTBUFFERSIZE * 10 / 8) {//XXX
> > > > +        dsyslog("clearing resultBuffer before sync");
> > > > +        Clear();
> > > > +        return NULL;
> > > > +        }//XXX
> > > >      for (int i = 0; i < resultCount - 3; i++) {
> > > >          if (data[i] == 0 && data[i + 1] == 0 && data[i + 2] == 1) {
> > > >             int l = 0;
> > > >
> > > > and let me know whether this message is ever logged, that would be
> > > > nice.
> > > >
> > > > Klaus
> > > Thanks for the test code.  I have rebuilt vdr with this patch and now
> > > I can not seem to reproduce the buffer overflow either... Could the
> > > extra time it takes to process this new code be preventing some kind
> > > of race condition?  So far I have not seen any "clearing resultBuffer
> > > before sync" messages... I'll keep testing.
I have been experimenting with this patch and have also applied the 
patch mentioned in another post by Reinhard Nissl about:

-           if (Count > TRANSFERBUFSIZE * 2 / 3) {
+           if (ringBuffer->Available() > TRANSFERBUFSIZE * 2 / 3) {

but, the same buffer overflows occur and I have not seen any messages 
about "clearing resultBuffer before sync" in my syslogs.  However, I do 
get messages about "clearing device because of consecutive poll 
timeouts". Im starting to notice that when I set a bunch of consecutive 
timers, that the first timer seems to always work.  The problem seems to 
occur when VDR has already initiated a prior recording, then must stop 
recording, then switch chans, then start a new TS.  Almost like VDR is 
not given enough time to recover from the previous recording.  If it is 
of any consequence, I have also noticed that when VDR must switch chans 
initiated by the timer, that it successfully starts a new TS but the 
picture on the tv is frozen with the image of the previous channel 
(until I manually switch chans to the one that is recording).

Thanks,