Tom Hughes wrote:
In message <[EMAIL PROTECTED]>
        Allan Stirling <[EMAIL PROTECTED]> wrote:


If we look at how szap does it, it's waiting for:
ioctl(fe_fd, FE_READ_STATUS, &status);
...
if (exit_after_tuning && ((status & FE_HAS_LOCK) || (++timeout >= 10)))
         break;

Yes, this isn't even as clean as polling for events.


That is effectively what Myth 0.18 does and I can assure you that it
sometimes fails on my system because the lock that is reported is for
the old multiplex as the card hasn't started retuning yet.

This is because there is now a kernel thread that does the tuning and
all the FE_SET_FRONTEND does is tell that thread to start tuning but
it sometimes takes a short while for the background thread to actually
start the tune and in that interval FE_READ_STATUS will still be
reporting a lock on the old channel.

My reading of the kernel last time I looked was that FE_GET_EVENT
would avoid that race and wouldn't indicate a lock until the new
multiplex was locked.

Tom

This code changed in R7125 to look for an event rather than polling for the FE_HAS_LOCK.

What I'm saying is with the new code, I don't get an event, therefore it doesn't realise tuning is done.


Cheers,

Allan.
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Reply via email to