Klaus Schmidinger wrote:
this should get worked around in the lowlevel frontend code, right? A majority decision would do the job: read out the status multiple times and report only consistent values to the generic layer...Johannes Stezenbach wrote:Then I don't know why you lose FE_HAS_LOCK, and especially why you still get a good signal even without FE_HAS_LOCK. It's expected that FE_RESET will break the signal, but the root cause is a broken lock indicator from the frontend.
If I remember correctly FE_RESET was initially intended to clear pending interrupt bits on frontends which hang or crash when you don't do so on a regular basis. This was the case for e.g. the L64781 until we found out that this happens only for particular output stream modes. The SP8870 problems sound similiar to me, but maybe we can clear the irq bits in the status readout ioctl, this should happen often enough...Anyway, we could do the following: - set a flag before tuning - in dvb_frontend_thread(): call FE_RESET ony if the flag is set - reset the flag when we get FE_HAS_LOCK -> FE_RESET will not be called if FE_HAS_LOCK drops out for short periods on an already tuned TP.Sounds good to me.