[vdr] Re: VDR developer version 1.3.14

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Laz wrote:
> 
> On Friday 29 Oct 2004 14:16, Klaus Schmidinger wrote:
> > Laurence Abbott wrote:
> > > Hmmm...I'm starting to think that the new buffer-handling routines are
> > > mores sensitive to artifacts in the signal due to weather, etc.
> >
> > I don't think that the changes to the buffer handling could cause this.
> > However, I did refurbish the code in cRemux that detects frame borders
> > (and thus picture types). Maybe I broke something in there...
> 
> That's probably what I actually meant :-s
> 
> Just looking through remux.c now. Do you have any good URLs for info on these
> DVB streams so I can see what it is doing?
> 
> > > I've found the //#define DEBUGRINGBUFFERS bit in ringbuffer.h but I'm
> > > not really sure what the output means to try to debug this!
> >
> > This prints a visual display of all ringbuffers, which is rather
> > helpful when testing buffer handling.
> 
> What should this output be like, ideally? At present, it spews out many lines,
> i.e. several screens full, to start with, with the head and tail pointers
> generally moving progressively to the right:

That's just fine.

>  0 >--------------------------------------------       -1       -1 Transfer
>  1 >--------------------------------------------       -1       -1 Result
>  2 -<>------------------------------------------    11280      188 TS
> 
>  0 ------<*>------------------------------------      188    55084 Transfer
>  1 ------->-------------------------------------     2048     5906 Result
>  2 --------->-----------------------------------    11280      188 TS
> 
>  0 -------->------------------------------------      188    55460 Transfer
>  1 ---------------->----------------------------     2048     4096 Result
>  2 --------->-----------------------------------    10716      188 TS
> 
>  0 -------->------------------------------------      188    55460 Transfer
>  1 ---------------->----------------------------     2048     4096 Result
>  2 --------->-----------------------------------    10716      188 TS
> 
>  0 -------->------------------------------------      188    55460 Transfer
>  1 ---------------->----------------------------     2048     4096 Result
>  2 ---------<>----------------------------------    11280      188 TS
> 
> etc.
> 
> After a while it will sit there for several minutes without outputting any
> more lines before spewing out another large number of lines before settling
> again. (I'm assuming that this is real and not some bizarre buffering of
> stdout!).

The buffer debug output is only generated if a recording or Transfer Mode
is currently going on.

> Similar things are seen during record and playback, e.g.:
> 
>  0 --------------------------------<>-----------      188    54708 Recorder
>  1 ----------------------------------<********>-     2048     4096 Result
>  2 -------------------------------------<>------    10528      188 TS
> 
>  0 ------------------------------------->-------      188    54896 Recorder
>  1 ----------------------------------<*********>     2048    18432 Result
>  2 ---->----------------------------------------    11468      188 TS
> 
>  0 ----------------------------------------->---      188    55084 Recorder
>  1 ------------------------<*********>----------     2048     2048 Result
>  2 --------------<>-----------------------------    11092      188 TS
> 
>  0 <>-------------------------------------------      188    54896 Recorder
>  1 -------------------------<********>----------     2048    14336 Result
>  2 -------------------------<>------------------    10528      188 TS
> 
>  0 ----->---------------------------------------      188    54708 Recorder
>  1 -------------------------<********>----------     2048     2048 Result
>  2 ------------------------------------->-------    10528      188 TS
> 
>  0 ---------<>----------------------------------      188    54896 Recorder
>  1 -------------------------<********>----------     2048    16679 Result
>  2 --->-----------------------------------------    11468      188 TS
> 
>  0 -------------->------------------------------      188    54708 Recorder
>  1 -------------------------<********>----------     2048     2048 Result
>  2 --------------<>-----------------------------    11280      188 TS
> 
> (Are the *s bad?!)
> 
> Is this the expected bahaviour, or should it just output one set on going ot
> transfer, playback, or record?

The "----------" marks the empty buffer area, while "********" marks occupied
buffer. '>' is the "head" (where new data is written) and '<' is the "tail"
(where it is read). If there is only a '>' it means that the buffer is (almost)
empty.

Klaus