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?
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
