[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