[linux-dvb] Re: Bug in software demux still in 2.6.10

[emard@softhome.net]

On Tue, Jan 04, 2005 at 02:56:21PM +0100, Wolfgang Wegner wrote:
> Hi,
> 
> sorry if I reply inappropriately without being in the position to test
> nor to have even looked at the code (and even off-list, because of the
> "wrong" email account at the moment)! And, sorry too for the bad quoting!
> 
> I really do not know if there is a connection, but this is what I just
> came to think about:
> 
> - some people (including a friend of mine) have problems when using a
>   second, budget, card to feed a full-featured card. This seems to
>   be especially a problem with DVB-T and even more when the card takes
>   long time to lock (maybe with some short, instable locks in between),
>   at least this is what that friend of mine found out.
>   In case of a problem, the ARM firmware locks and gets command timeout
>   errors.

This is not (only) a software demux problem, which run on budget and 
feeds the card with ARM. ARM crash likes to happen if the ARM is fed 
by any garbled data that looks like original data but has errors inside, 
therefore dvb-s having clean signal crash ARM 'rarely' (mine crashes 
every 30 minutes) while dvb-t owners see that crash more often.

Software demux can rarify the problem by strengthening the data
consistecy chekings, but can't help from ARM crashes. Even if you 
have some magic filter application that analyzes garbled stream,
cuts off errors, re-packs the rest of valid data and feeds this
to ARM card, you would still have few bugs in ARM/firmware remaining
to be fixed before crash-free situation is achieved.

> Most of the problem reports are from DVB-T useres, maybe because they
> all _have to_ use a second card as a primary data source because there
> are not many FF-DVB-T-cards out there. Furthermore, due to the low symbol
> rate, DVB-T unavoidably needs longer lock times.

Longer lock times = greater amount of garbled data until the lock sets on
= higher frequency of ARM bugs

> Could this bug in the software demux maybe cause the ARM to crash?

NO, bug is in ARM firmware

Emard