[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect
Michael T. Dean
mtdean at thirdcontact.com
Wed Jul 19 16:49:29 UTC 2006
On 07/18/2006 03:08 PM, MythTV wrote:
>#2060: US cable frequency tables incorrect
>
>Comment (by danielk):
>
> I mostly used the frequencies in frequencies.c to build the table.
>
> The T-# channels did disagree with the ones in the URL you referenced. One
> of them has to be wrong...
>
Yeah, Daniel, I think the ones defined in Myth's frequency tables are
incorrect.
There was a couple of threads where people were trying to attribute
tuning issues to "incorrect" frequency tables in Myth. I had reassured
them that the tuner hardware's fine-tuning algorithm would take care of
the differences, but was unable to convince them. So, thinking the
easiest way to prove that it's not due to inexact values in Myth's
frequency tables was to allow them to use "academically correct" values
in Myth. I created a patch to "fix" the tables to use the
academically-correct values (instead of the values we've been using).
During this I noticed that T-7 through T-14 are incorrect according to
http://www.jneuhaus.com/fccindex/cablech.html, which agrees with the
listing provided by the bug reporter (
http://www.atxnetworks.com/qrf/catvfrq1.htm ) (although my URL provides
a value for T-14, and the reporter's URL skips it).
For the patch I made and information about the discrepancies I noted,
see http://www.gossamer-threads.com/lists/mythtv/users/177901#177901 .
Search for capital 'T' in the patch to go right to the section on the T
band.
If we do make changes, I recommend we:
- fix the T band frequencies in ntsc_cable (standard)
- fix the HRC and IRC lists to remove the T-band channels (HRC and
IRC standards don't define a T band)
- (no matter what we decide about "fixing" frequencies in HRC and
IRC) leave ntsc_cable frequencies (other than T band) unmodified (since
we've chosen the value from which cable companies are required to offset
and since some companies use a positive and others use a negative
offset, we can't make it academically-correct without making two
frequency tables for standard)
- ignore all the frequency "fine-tuning" in HRC and IRC. (Modifying
these values would--if nothing else--make the finetune values some users
have specified in the database "incorrect" since they'd be applied to
different frequencies, and in the worst case could cause tuning issues
for some users who have specified finetune values.) Since the
hardware's fine-tuning algorithm should take care of all the
discrepancies we have, it's not, IMHO, worth the risk of breaking things
(which is why I didn't make the IRC values academically correct when
updating a 0.18.1 patch to work SVN--the values were tested by the guy
who did the first patch and I couldn't test the modified ones, so it was
better to leave them).
If this sounds good to you, let me know and I'll create a patch (for the
analog part, at least--which could show you what changes need to be made
for the digital).
If we want to make the HRC and IRC frequency tables academically
correct, though, we could also do the frequency fine-tuning. Note,
though, that I've never actually had someone willing to test the new
frequency tables (giving them the option to use them has always been
enough to convince them it's not the frequency tables ;). Finding
someone to test the corrected frequency tables will likely be the
biggest challenge (unless we commit first and revert if necessary :).
Mike
More information about the mythtv-dev
mailing list