vdr-xine: what's wrong with this piece of code-- threadingissue?

  On Fri, 2005-03-25 at 23:54 +0100, Reinhard Nissl wrote:
> Hi,
> 
> Rantanen Teemu wrote:
> 
> >>This typically happens when moving cutting marks, and I'm
> >>investigating this already.
>  >>
> >>Expect it for 0.8.0, but the next release will still be 0.7.3.
> > 
> > Looking forward to both 0.8.0 and 0.7.3 ...
> > 
> > In my experience the most problems I've had are starting/ending
> > recording, and all rewinds. At these points may happen that xine
> > disconnects. Not very often but sometimes. When xine disconnects VDR
> > will "play" the recording really fast and it's minutes past the place
> > when xine reconnects. I've had no problems with cutting marks...
> 
> Please apply the attached patch to vdr-1.3.23 and tell me, whether there 
> is any improvement. At least there was one for me ;-)

Definitely improves fast forward, rewind, and stuck still picture issues
here with DXR3.  But, so does the attached patch from the old DXR3
plugin, the functionality with yours or the attached patch seems
identical here.  Any comments?
  

Hi,

Ville Skyttä wrote:

>>>>This typically happens when moving cutting marks, and I'm
>>>>investigating this already.
>>>>
>>>>Expect it for 0.8.0, but the next release will still be 0.7.3.
>>>
>>>Looking forward to both 0.8.0 and 0.7.3 ...
>>>
>>>In my experience the most problems I've had are starting/ending
>>>recording, and all rewinds. At these points may happen that xine
>>>disconnects. Not very often but sometimes. When xine disconnects VDR
>>>will "play" the recording really fast and it's minutes past the place
>>>when xine reconnects. I've had no problems with cutting marks...
>>
>>Please apply the attached patch to vdr-1.3.23 and tell me, whether there 
>>is any improvement. At least there was one for me ;-)
> 
> Definitely improves fast forward, rewind, and stuck still picture issues
> here with DXR3.  But, so does the attached patch from the old DXR3
> plugin, the functionality with yours or the attached patch seems
> identical here.  Any comments?

Well, the code below looks like my first step into this direction: I was 
just adding 4096 bytes instead of all data up to the next I-frame.

Anyway, the code below doesn't fix this issue proplery for xine.

> ------------------------------------------------------------------------
> 
> Workaround for I-frame display problems when cutting (still picture not
> updating) and/or fast forward/backward in some streams.
> Apply to: VDR sources
> More info: http://www.schluenss.de/history.html
> 
> --- recording.c.orig	2005-02-12 12:17:47.000000000 +0200
> +++ recording.c	2005-03-14 23:01:32.370785864 +0200
> @@ -1017,8 +1017,8 @@
>                    FileOffset = &index[Index].offset;
>                 if (Length) {
>                    // all recordings end with a non-I_FRAME, so the following should be safe:
> -                  int fn = index[Index + 1].number;
> -                  int fo = index[Index + 1].offset;
> +                  int fn = index[Index + 2].number;
> +                  int fo = index[Index + 2].offset;
>                    if (fn == *FileNumber)
>                       *Length = fo - *FileOffset;
>                    else {
> 
> ------------------------------------------------------------------------

Bye.