Yes. There was a bug in the dvb-kernel which together with the lock
detection in cDvbTuner:Action() caused the indication of a lock if
actually there is no stable lock.
VDR assumes a valid lock if it gets the first 0x1f FE status event (the
first rising edge of FE_HAS_LOCK so to say). This holds until the next
tuning. With DVB kernel I observed 2 situations:
1. Tuning from a locked channel to a channel where no lock can be found:
The first status events are 0x00, 0x1f (nearly at the same time) ->
HasLock = true. Abt. 100ms later the FE status changes to 0x01 or 0x03
but HasLock stays true. This happens on the 2nd card while trying to
tune to a channel number 0 (what does this mean btw?).
2. Tuning from a locked channel to another valid channel:
VDR gets events 0x00/0x1f immediately after setting the frontend. This
is not correct too (I assume a frontend can not retune to a new channel
in < 1ms)
So my suggestions would be:
1. Check that FE_HAS_LOCK remains stable for some time. I'm using 300ms,
which may be a little longer than necessary. See my patch to
cDvbTuner::Action() I posted on this list recently.
2. Use the fixed DVB kernel driver.
With modification 1 alone I have not got any more errors. This does not
mean that this is the solution for all of the VDSB etc. errors. I think
there are a number of different reasons for these errors.