On Sun, 2005-09-11 at 04:04 +0200, Kenneth Aafløy wrote: > > I don't like this, it violates the principle of least surprise. > > Normal everyday actions such as changing channels and making > > recordings should not mess with the transponder/multiplex table. > It should not modify the original value in the database, but either enter it > into a separate field or as a list in the frequency field. That might work.
> > This capability is already present in DVBSignalMonitor... You just > > have to add the kDTVSigMon_WaitForMGT or kDTVSigMon_WaitForNIT flag, > > for ATSC or DVB, resp. > Hu, the NIT can take a huge time to get, why not SDT as that's transmitted > more frequently, or event the PAT? Well actually it uses the PAT right now for DVB channels, and a VCT for ATSC channels. I thought you wanted to verify the NIT. (It caches the VCT pids from previous tunes, but also waits for MGTs in case the VCT pids are out of date.) > > I don't expect this to swing widely very often. > Hmm, wonder if that reasoning applies here: > - My LNB sits on the sunny wall, like everyone elses, which would easily > cause a very large temperature difference. Not to mention summer and winter. > - The LNB converts the frequency of the signal down about 1Ghz. I didn't think of this; an LNB sitting in the sun, even in a white ventilated PVC case will experience huge temperature swings. Maybe caching some dated frequency values is worth the effort. Can you chart the drift on a transport over a 24hr period, once per hour say? If the drift is is like 100 kHz it's not worth the effort, but if it is closer to 500 kHz it is. -- Daniel _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
