Hi, Olaf Titz wrote: > Something changed between VDR 1.3.34 and 1.3.42 which leads to a much > higher rate of (apparent) TS read errors. I'm getting corrupted > pictures and no sound with repacker error messages all the way with > .42 or .43, while .34 is okay. This happens on two different machines > with different hardware (FF vs. budget DVB-S card) and kernel > versions. > > I have no real idea which change caused the problem, but this seems to > cure it: > > --- dvbdevice.c 25 Feb 2006 09:46:06 -0000 1.1.1.2 > +++ dvbdevice.c 25 Feb 2006 12:01:30 -0000 1.2 > @@ -1179,7 +1179,7 @@ > CloseDvr(); > fd_dvr = DvbOpen(DEV_DVB_DVR, CardIndex(), O_RDONLY | O_NONBLOCK, true); > if (fd_dvr >= 0) > - tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(2), CardIndex() + 1); > + tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(5), CardIndex() + 1); > return fd_dvr >= 0; > } > > Perhaps the repacker changes need somehow more buffer space, packets, > processing time (but I have <50% CPU load even with xine on one box) > or whatever? We (me and Klaus) have got a report from Wolfgang Goeller in early November 2005 that he has a similar issue on Swiss channels and that increasing the TS buffer size almost fixes his' issues. Strange is, that the TS buffer has never reported an overflow, as in your case. I never had such errors since last Sunday. As I wanted to send my PATA drive in for repair, I've replaced it by a SATA one. Now I get dropped TS packets with almost every disk access. I've asked on the linux-dvb mailing list whether this is a known issue and I got a reply to test a patch of Ingo Schneider which changes the SAA7146 DMA buffer handling of my NOVA-S card, but I didn't find time so far. So maybe it is worth a test for you, too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@xxxxxx
