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
