Wolfgang Fritz wrote:
>
> What I find strange is that dvb_frontend_thread adds an FE event while it is in FSM
> state
> FESTATE_RETUNE. If I understand the code correctly, nothing has happened to the
> hardware up to now
> and the thus the FE state reflects the last state of the previous tuning. This does
> not make sense
> to me. I attach a patch that resets the FE state to 0 and does not add an event if
> the FSM is in
> state FESTATE_RETUNE. It removes the "spike" and otherwise seems to work as before.
> --- dvb_frontend.orig.c 2004-08-01 12:32:44.000000000 +0200
> +++ dvb_frontend.c 2004-08-01 13:13:27.000000000 +0200
> @@ -520,10 +520,14 @@
> }
>
> // get the frontend status
> - dvb_frontend_internal_ioctl (&fe->frontend, FE_READ_STATUS, &s);
> - if (s != fe->status)
> - dvb_frontend_add_event (fe, s);
> -
> + if (fe->state & FESTATE_RETUNE) {
> + s = 0;
> + } else {
> + dvb_frontend_internal_ioctl (&fe->frontend, FE_READ_STATUS,
> &s);
> + if (s != fe->status) {
> + dvb_frontend_add_event (fe, s);
> + }
> + }
> // if we're not tuned, and we have a lock, move to the TUNED state
> if ((fe->state & FESTATE_WAITFORLOCK) && (s & FE_HAS_LOCK)) {
> update_delay(&quality, &delay, fe->min_delay, s & FE_HAS_LOCK);
This patch looks good to me.
Comitted to CVS.
Thanks,
Johannes
