[linux-dvb] Re: TS Continuity problem reason found for budget-cards

[Markus Schulz <msc@antzsystem.de>]

Michael Hunold wrote:

> Hi,
>
> Am 12/01/04 11:19, Markus Schulz schrieb:
>
> > i've build a ts-continuity check for one pid (hardcoded) in
> > dvb_demux.c:dvb_dmx_swfilter_packets and find out that there are the 
> > place where packets lost.
> > this happens cause the ts-sync byte sometimes don't find at position 
> > 0 in buffer but at position 1 or (possible) other.
>
> Interesting. Do you have more informations about the garbled TS packet?
> If it starts at position 1, is it only 187 bytes long? Or is it 188 
> bytes long (and valid) and the following packets are only shifted 
> throughout the buffer?

okay, i've looked a bit deeper into lost packets.
here some output:

Dec  1 23:59:21 nias kernel: Sync Byte found for count=150 von 348 for 
pid 255and cont-counter 3 at pos = 1
Dec  1 23:59:21 nias kernel: Dump from buf[0] to buf[sync found]
Dec  1 23:59:21 nias kernel: ******************************************
Dec  1 23:59:21 nias kernel:  80
Dec  1 23:59:21 nias kernel: ******************************************
Dec  1 23:59:21 nias kernel: Dump found paket (188+4 bytes)
Dec  1 23:59:21 nias kernel: ******************************************
Dec  1 23:59:21 nias kernel:  47 00 ff 13 6a 85 85 10 24 dd b0 50 b0 c3 
a0 0f 63 75 7a 81 87 ff e4 b3 69 1b dd 5d 9f 64 9a a9 13 80 e4 d7 62 d5 
07 46 99 42 fd a0 50 20 5d bc 3b 80 0e ad 37 6c 04 00 7e 4d bc b9 55 93 
40 2c b4 02 04 39 97ee 60 1a c2 ea 88 e9 a1 d4 64 2c 00 6f 42 41 46 3a 
fd d0 96 62 23 1e 96 03 10 00 00 01 10 42 78 4b 9d 09 2f f4 a1 51 c2 3b 
55 b0 10 02 6d 67 4f 0a bc c4 eb 31 af 9d 26 c7 55 54 69 d5 ce 8d 8d 01 
f5 5b 01 88 af 67 cd 68 16 28 01 7d c9 c3ac e5 40 7a ae 36 34 00 6d 35 
a0 9c 7c 5d dc 59 96 c2 4a 10 22 75 cf 76 80 42 09 f5 58 9b 8d b6 02 21 
3a 80 65 3d db 47|<188>| 02 ff 19 74
Dec  1 23:59:21 nias kernel: ******************************************


There you can see, that after 187 bytes from found sync byte, the next 
TS packet starts.(i've set a mark |<188>| at position 188)

It seems for me that the 0x80 in this example must be from the lost 
packet, but where should it go?
The header of lost packet seems to be fine.


a hardware problem can be excluded cause it works fine with windows driver.

Markus Schulz