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

[Allan Stirling]

Tom Hughes wrote:
> 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
> 
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.