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
