[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