[mythtv] [PATCH] Remove use of deprecated DVB events.
Mark Weaver
mark-clist at npsl.co.uk
Thu Sep 1 17:38:30 UTC 2005
Stuart Auchterlonie wrote:
> On Thu, Sep 01, 2005 at 04:54:45PM +0100, Stuart Auchterlonie wrote:
>
>>Hmmm, changing between channels on the same mplex the backend
>>gets stuck in select waiting for an event. This leads to the conclusion
>>that we are eating too many events. How or why I'm not sure at the
>>moment.
>>
>
>
> Okay I have worked out what is going on.
>
> When we are in TuneTransport there are 3 types of events that
> are delivered.
>
> 1) Event with freq = old_tuned_freq && status == 0
> 2) Event with freq = old_tuned_freq && status != 0
> 3) Event with freq = new_freq && (status & FE_HAS_LOCK)
>
>
> Those of us using DVB-T normally get either 2 or 3 events in total.
> One of each of the first 2, and then one of the third if we are
> changing frequency (& hence mplex)
>
This is tuner trying to get a lock and then getting one. However you
are looking at old events from the previous tune since the event queue
is not drained when we eventually get a lock. If no FE_SET_FRONTEND
takes place (because it is deemed unnecessary by TuneXXX) then you will
be polling for old events (the now unused variable havetuned). If you
manage to suck them all out then you will be stuck with a timeout, even
if the tuning completes successfully.
I think that the correct approach would be something like:
1. drain the event queue [with check for EOVERFLOW]
2. try tuning
3. if we didn't need to tune, return immediately
while (some time remains)
4. wait for an event (poll/select) with a timeout
5. discard the event if available, otherwise ignore the failure [EOVERFLOW]
6. read the frontend status and check for lock
7. repeat until timeout
This should avoid two issues that have occurred so far:
1. Some cards report the actual locked on frequency in the status rather
than the requested frequency. We don't test the frequency, just the
lock status, so this should be OK.
2. The FE_READ_STATUS race in < 2.6.13 is avoided by waiting for an
event after a tune.
This has the following issues:
1. We are waiting for a signal lock after tuning, Daniel indicated that
this is the job of the signal monitor -- that causes other problems
though. For me personally tuning happens so quickly that it isn't worth
the extra complications caused by not waiting, but according to
dvb-core/dvb_frontend.c some cards actually end up moving a satellite
dish or similar. So tune could really take a _long_ time to complete.
For those of use with things that don't move like aerials then this
isn't an issue.
2. We are relying on FE_GET_EVENT returning something. This is easily
worked around if it is broken for some reason, you just use a shorter
timeout on the poll/select call and effectively poll the status. (Has
the advantage over sleep polling that if the event interface is not
broken then it gets the lock status faster than with a sleep).
It would seem due to #1 that Daniel's patch is actually along the right
lines, it's just that there are other issues that then crop up. Hence
I've elected not to write any more code (Kenneth's poll() loop works ok
for me at present).
Any thoughts?
Thanks,
Mark
More information about the mythtv-dev
mailing list