TS buffer size

Message ID E1FCz7U-0006v9-00@bigred.inka.de
State New
Headers

Commit Message

Olaf Titz Feb. 25, 2006, 1:05 p.m. UTC
  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:

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?

Olaf
  

Comments

Reinhard Nissl Feb. 25, 2006, 2:23 p.m. UTC | #1
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.
  

Patch

--- 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;
 }