Hi,
Reinhard Nissl wrote:
> Please provide me some of these files which were dumped in the "middle"
> of a recording. If size matters, you may reduce the number of packets to
> 100.
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
will give you something like the lines below (I've croped the long lines
here for readability). Just have a look a the marked column:
v
v
02d06c 47 02 94 13 24 84 c0 8b
02d128 47 02 94 14 44 91 b9 1b
02d1e4 47 02 94 15 a5 ab ab a1
02d2a0 47 02 94 16 40 b4 0c c2
02d35c 47 02 94 17 5d c5 6b 5f
02d418 47 02 94 18 72 5c 3e 84
02d4d4 47 02 94 19 05 81 b4 7e
02d590 47 02 94 1a 95 ba dc 2c
02d64c 47 02 94 1b 86 86 fe 12
02d708 47 02 94 1c 2b 22 a6 d9
02d7c4 47 02 94 1d b9 b5 e2 6d
02d880 47 02 94 1e e4 6e 11 17
02d93c 47 02 94 1f 90 00 00 00
02d9f8 47 02 94 10 ca 1b 20 ed
02dab4 47 02 94 11 55 d5 c6 73
02db70 47 02 94 10 e8 69 4d 5a
02dc2c 47 02 94 11 d8 e5 9a 69
02dce8 47 02 94 12 ac 2a 65 ba
02dda4 47 02 94 13 62 35 d1 c4
02de60 ^
^
This nibble represents the TS continuity counter. It cycles properly
from 0 to 9 and a to f throughout the file. But near the end the
following sequence appears:
e f 0 1 . . . . . . . . . . . . . . 0 1 2 3
The dot's indicate at least the missing TS packets with counter values:
_ _ _ _ 2 3 4 5 6 7 8 9 a b c d e f _ _ _ _
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
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
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).
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. But when
you start a recording for example on a single FF card system, TS packets
will then be sent to VDR for the recording and for live TV, so if you
continue to watch the recorded channel, you'll typically get the
cRepacker messages twice for different threads.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
