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.