[vdr] FF card AV sync problems, possible fix to VDR (fwd)

Kartsa kari at kniivila.com
Wed Feb 21 18:59:18 CET 2007


Reinhard Nissl kirjoitti:
> I had a look into the files you've provided me. It looks like some TS
> packets get lost. You can simply check this on your own:
>
> 	od -Ax -t x1 -w188 -v ts_10973_11079_0xC0_004_116796_1000.log \
> 		| tail -n 20 | less -S
>
> I wonder why you didn't get lines like the following in your logfile
> after enabling the earlier mentioned source lines and specifying
>
> 	-l 3
>
> on VDR's command line to turn on debug log messages:
>
> Feb 20 21:41:14 video vdr: [27499] TS continuity error (1)
> Feb 20 21:41:15 video vdr: [27499] cTS2PES got 0 TS errors, 1 TS
> continuity errors
>   
This has been very illuminating. Maybe I made some mistake with the 
logging because there really is no TS continuity error in the log. I 
definitely have -l 3 on commandline (just checked with ps -ef). And I 
also checked that I had activated the line in remux.c. And I now that I 
have used that remux.c while compiling because it is the same that I 
used your patch against. So I do not know why there is no TS continuity 
errors on log.
> Sad to say, I can hardly help you further as lost TS packets can be
> caused by a couple of reasons:
>
> - Dish alignment
> - Weather conditions
> - Cabling
> - Interference with DECT telephones
> - DMA/PCI mainboard issues
> - High system load / latency
> - DVB driver issues
>   
I am in cable so dish can not be the problem, nor the weather. Cabling 
is one (including the operators cables) and I suspect a hw issue (or 
DMA/PCI) as I have sata drives. Telephones can always be a problem but I 
do not think that this often. High load is not a possibility unless vdr 
is causing the load :) And ofcourse there is the driver. But mostly I 
suspect the cable operators cables because even the analog picture is 
not too good and I get cAudioRepacker skipped messages on my other vdr 
also (but after fifth simultaneous recording). Ofcource the firmware is 
the same. I think I must try the older fw on the other to see if it 
makes any difference.
> As you can see, VDR just picks up what survived the above stages.
>
> I had lost TS packets over and over just after replacing my PATA drive
> by a SATA drive to have the PATA one sent in for repair. I've contacted
> the dvb-mailing list and got driver patches for larger DMA buffers.
> Extremely large buffers seemed to fix the problem but not completely.
> After the PATA drive returned from repair, I've removed the SATA drive
> and -- you won't believe it -- everything worked out of the box as
> before, even with default drivers (I won't blame here SATA in general --
> this is just my personal experience at that time with certain hardware).
>   
This is why I am using different mb model and a pata drive on a new vdr 
I am just building for a friend. I will inform you about how that one works.
> BTW: You may wonder why you do not get these messages when watching live
> TV with a FF card. The answer is simple: the TS packets never leave the
> card in this case, so VDR has no way to report such an issue for example
> in case where the problem would be related to dish alignment.
I have no problems with the live TV. Never had any problems with that.

Anyway thanks for your input and support.

\\Kartsa



More information about the vdr mailing list