[mythtv] dvbchannel patch

Mark Weaver mark-clist at npsl.co.uk
Wed Aug 31 04:29:43 UTC 2005


> Basically this happens when changing frequencies -- it's not getting the 
> right PAT, fails to find the program, and then locks up.  At least, this 
> is how I read the log (see attached).  Any ideas?
> 
OK, I think this is because mpeg table monitoring is being set up before 
the signal lock event has been received:

2005-08-31 05:00:31.828 mpeg program number: 4415
2005-08-31 05:00:31.829 DTVSM(0)::SetProgramNumber(4415):
2005-08-31 05:00:31.830 SM: RemoveFlags: Seen(PMT,) Match(PMT,) Wait()
2005-08-31 05:00:31.831 SM:    AddFlags: Seen() Match() Wait(PMT,)
2005-08-31 05:00:31.832 SM:    AddFlags: Seen() Match() Wait(PAT,PMT,)
2005-08-31 05:00:31.834 Successfully set up MPEG table monitoring.
2005-08-31 05:00:31.835 SM(0)::Start: begin
2005-08-31 05:00:31.837 SM(0)::Start: end
2005-08-31 05:00:31.839 DTVSM(0)::GetStatusList: WaitForPMT seen(0) 
matching(0)
2005-08-31 05:00:31.868 DVBSM(0)::UpdateValues(): Signal Lock
2005-08-31 05:00:31.882 DVBSM(0)::RunTableMonitor(): begin (# of pids 2)
2005-08-31 05:00:31.886 DVBSM(0)::AddPIDFilter(0x0):
2005-08-31 05:00:31.887 DVBSM(0)::AddPIDFilter(0x1ffb):
2005-08-31 05:00:31.890 MPEGStreamData::HandleTables: got a PAT

I'm guessing that data is being read from the old signal, which 
sometimes contains a PAT, which then leads to the wrong PAT being used. 
  I think that it is wrong to set up table monitoring before a signal 
lock has been obtained.  This also explains why my channel changing 
patch works for me -- it always waited for a lock.  I guess the fix for 
this is to wait for a signal lock before reading data?

At this point, I'm not really clear on why the waiting for a signal lock 
should be asynchronous.  Is this for user feedback in the event that 
some cards take a long time to tune?


More information about the mythtv-dev mailing list