[mythtv] Current DVB problems rundown
danielk at cuymedia.net
Sun Sep 11 05:38:08 UTC 2005
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.
More information about the mythtv-dev