[mythtv] [mythtv-commits] Ticket #2060: US cable frequency tables incorrect

[Michael T. Dean]

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