[mythtv] Re: [mythtv-commits] mythtv commit: r7128 by danielk

Tom Hughes tom at compton.nu
Thu Aug 25 11:36:00 UTC 2005


In message <430D907A.9000902 at pendor.org>
        Allan Stirling <Dibblahmythml0015 at pendor.org> 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

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/


More information about the mythtv-dev mailing list