[linux-dvb] Re: Vdr "video data stream broken"

[a.share@t-online.de (Andreas Share)]

> Andreas Share wrote:
>
> >Hmm, my skystar2 rev 2.6c/stv0299 dies within 2-3h, but my nova (like
> >budget-ci) and my ff rev 1.5 sometimes run for ~12h...
> >
> >i have seen the skystar2 irq_handler calls dvb_dmx_swfilter_packets()
more
> >often than the other cards
> >
> >if (adapter->capturing != 0) {
> >   dvb_dmx_swfilter_packets(dvbdmx, pb_dma_buf_cur_pos,
> >dw_default_packet_size / 188);
> >  }
> >
> >at: "u32 dw_default_packet_size = 188;"
> >
> >so i think every call deliver one packet.
> >
> >
>
> Yes it does, but if you look at dvb_dmx_swfilter_packets() it simply
> loops around passing the TS data 188 bytes at a time to another routine,
> so it should not make much difference.
>
> What does "vmstat 1" report about the number of IRQ/s on your machine
> when the card is running?
>
> I took a look at the Skystar buffer handling and it appears that it
> passes around 100kB of data in each interrupt, which is similar to the
> budget driver.
>
> If you look at dvb_dmx_swfilter_packets() you'll see that it expects the
> TS packet to start with 0x47. Perhaps a problem causes it to lose sync
> and so all the packets get dropped. The patch attached should tell you
> when this occurs. You may see a few messages caused by transient errors,
> but the important thing is if you see a lot immeadiately before VDR
> reports the broken stream.
>
> Currently the drivers assume that the hardware will always provide the
> TS stream perfectly aligned on 188 byte boundaries.
>
>     Jon

Hi,

I have around 1600-1800 interrupts per second, with the ss2 as secondary
device during epgscan.

[root@amd-linux root]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu--
--
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id
wa
 1  0      0 124892  10804 270512    0    0    81    26 1578  1109  7  3 88
3
 0  0      0 124892  10804 270512    0    0     0     0 1571   953  5  3 92
0
 0  0      0 124892  10804 270512    0    0     0     0 1628   998  4  1 95
0
 0  0      0 124892  10804 270512    0    0     0     0 1573   980  4  4 92
0
 0  0      0 124892  10804 270512    0    0     0     0 1656  1052  6  2 92
0
 0  0      0 124892  10804 270512    0    0     0    16 1567  1011  5  4 91
0
 0  0      0 124892  10804 270512    0    0     0     0 1682  1059  5  4 91
0
 0  0      0 124892  10804 270512    0    0     0     0 1566   967  5  2 93
0
 0  0      0 124892  10804 270512    0    0     0     0 1640  1032  4  2 94
0
 0  0      0 124892  10804 270512    0    0     0     0 1598   970  4  2 94
0
 0  0      0 124892  10804 270512    0    0     0     0 1632  1040  5  2 93
0


One other thing: The Dbox2 related Tuxbox Project share the Api3 and the
most of the core driver stuff with us. And they have similar problems.
Sometimes the boxes deliever no more audio/video, and sometimes the boxes
have no picture but sound at the german "ARD" channel. They have track them
down to framer crashes, and i think we have the same problem. The tuxbox now
check the framer status and reset it in case of a crash....

IIRC this problems on dvb cards *and* the dbox2 was "indroduced" in API3, so
i think there is a piece of code (or some timing problems) in the core stuff
causes the crashes.

Is there any way to check the framer status on the different dvb cards? If
yes, we could improve the error handling in case the framer crashes.

Andreas