Lørdag 10 september 2005 08:04, skrev Daniel Kristjansson: > On Sat, 2005-09-10 at 04:37 +0200, Kenneth Aafløy wrote: > > IMHO, first of all we should store the frequency of the last succesfull > > tuning event, so that this could be used in any later tunings. > > 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. > > We must however support checking that the transponder/multiplex is the > > one we want before storing the last good frequency! > > 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? > > If something goes wrong with tuning the stored frequency, the original > > could still be tried after some grace period. > > I don't expect this to swing widely very often. Even those > mountain-top transmitters are serviced fairly often and are > usually climate controlled, so the drift shouldn't be that bad. 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. - The transmitter is located fairly far away, and definatly has no climate controll! > Most of the time the frequency will be wrong simply because the user > used the wrong frequency table. Situations like John Poet's where > a new antenna/transmitter is being tested will be the exception not > the rule. Right, nothing we can with keyboard problems, exept perhaps trying to tune the parameters right away and emit a warning if it failed! Kenneth _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
