Hallo Reinhard,

christian jacobsen wrote:

...

2620 - since 29. Aug. - with vdr-1.3.30 + 29

Here a list of the DVD drivers I used, I allways started

using them on

...

the Day that I downloaded them : Up till vdr-1.3.17 - dvb-kernel-20041221 vdr-1.3.19 - dvb-kernel-20050118 vdr-1.3.23 - dvb-cvs-kernel-20050324) vdr-1.3.25 - dvb-kernel-20050617 vdr-1.3.27 (20. June) - back to dvb-kernel-20050324 (more stable) vdr-1.3.29 - dvb-kernel-20050826 (together with FW 2620)

So if I see this right it comes down to that it probably is

caused by

...

the New Firmware or maybe something that was changed in VDR = 1.3.25 ?

cVideoRepacker was introduced. But it was wrong to reset it's scanner and drop any buffered data when it discovered a system start code. This resulted in putting incomplete PES packets into result buffer and later, it was possible that cRemux::Get() couldn't return any remaining data of result buffer. The result was that the receiver's ringbuffer filled up and caused an overflow as the recording thread could no longer feed cRemux due to the almost full result buffer. And finally, the recording thread caused an emergency exit as it didn't see any further data for 30 seconds.

Since VDR-1.3.25 there have been many fixes and improvements. The attached files will soon be released in VDR-1.3.32.

OK, I will try VDR-1.3.32 and see if it has been fixed.

A further change happend in VDR-1.3.31: waiting for the tuner to get locked on the signal before attaching the receiver was removed. Several versions ago, this waiting was introduced to fix the VDSB error. But it was removed now as no driver should need this waiting besides it is buggy.

Driver ist quite new 26.08.2005 so that shpuld be no problem. Otherwise if I get trouble again with VDR 1.3.32 I can try the attached Versions - with what VDR versions would they work ?

Thanks for looking into this :)

Greetings Christian Jacobsen