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

Allan Stirling Dibblahmythml0015 at pendor.org
Thu Aug 25 09:33:46 UTC 2005


mythtv at cvs.mythtv.org wrote:
>       Author: danielk
>         Date: 2005-08-25 01:37:37 +0000 (Thu, 25 Aug 2005)
> New Revision: 7128
>    Changeset: http://cvs.mythtv.org/trac/changeset/7128
> 
> Modified:
> 
>    trunk/mythtv/libs/libmythtv/dvbchannel.cpp
> 
> Log:
> 
> Another part of the "DVB channel flipping" fix.
> 
> This flushes all DVB frontend events before tuning and then
> waits for the first event after the tune.
> 
> My first inclination would have been to wait for an event
> with a status of FE_HAS_SIGNAL, but my card at least doesn't
> send any events after the first one (with no flags) until 
> there is a lock.
> 

After these event changes, I get no lock notification in an existing 
transport scan.

I'm using a dvb-ttpci.

2005-08-25 10:21:05.070 SIParser: Resetting all Table Handlers
2005-08-25 10:21:05.070 SIParser: SIParser Reset due to channel change
2005-08-25 10:21:05.073 DVB#0 Frequency: 10714250 Symbol Rate: 22000000 
Pol: H/L Inv: Auto
2005-08-25 10:21:05.073 DVBEvents: Flushing Event 
Status(Signal,Carrier,FEC Stable,Sync,Lock,) frequency(963491 Hz)
2005-08-25 10:21:05.074 DVB#0 DiSEqC 1.0 Switch - Port 0

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.

I'll work on a patch later, if this is as simple as I think.

Cheers,

Allan.


More information about the mythtv-dev mailing list