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