>> Hi Rob >> >> would you mind very much posting a patch that implements these two >> reversions, >> so I can try it easily? My hg-fu is somewhat lacking... >> I have the same hardware and noticed what I think is the same issue, >> just with Channel 9. >> Another manifestation is huge BER and nonzero REC in the output from >> 'tzap'. >> >> Kind regards, >> Vince > revert patch attached My problem was also mostly with Channel 9, but other channels also exhibited issues, although less often. Given the original checkin message of http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 was "Both ATSC and DVB @ 6MHz bandwidth require the same offset. While we're fixing it, let's cleanup the bandwidth setup to better reflect the fact that it is a function of the bandwidth." How about the attached patch which reverts e6a8672631a0 and 966ce12c444d but without the "cleanup" which breaks my DViCO. Could people who had the original 6MHz issue please test and report back Thanks -Rob > >> >> >> On 11/26/09, Robert Lowery <rglowery@xxxxxxxxxxxxxx> wrote: >>>> Hi, >>>> >>>> After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 >>>> (rev >>>> 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d >>>> everything >>>> appeared to be ok, but I have now noticed certain channels in >>>> Australia >>>> are showing corruption which manifest themselves as blockiness and >>>> screeching audio. >>>> >>>> I have traced this issue down to >>>> http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies >>>> for >>>> DVB @ 6MHz) >>> Actually, in addition to the above changeset, I also had to revert >>> http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T) to >>> get >>> things going. Seems this one might have been an attempt to fix an >>> issue >>> introduced by the latter, but for me both must be reverted. >>> >>> -Rob >>> >>>> >>>> In this change, the offset used by my card has been changed from >>>> 2750000 >>>> to 2250000. >>>> >>>> The old code which works used to do something like >>>> offset = 2750000 >>>> if (((priv->cur_fw.type & DTV7) && >>>> (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) || >>>> ((priv->cur_fw.type & DTV78) && freq < 470000000)) >>>> offset -= 500000; >>>> >>>> In Australia, (type & DTV7) == true _BUT_ scode_table == 1<<29 == >>>> SCODE, >>>> so the subtraction is not done. >>>> >>>> The new code which does not work does >>>> if (priv->cur_fw.type & DTV7) >>>> offset = 2250000; >>>> which appears to be off by 500khz causing the tuning regression for >>>> me. >>>> >>>> Could any one please advice why this check against scode_table & >>>> (ZARLINK456 | DIBCOM52) was removed? >>>> >>>> Thanks >>>> >>>> -Rob >>>> >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>>> in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>> in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" >> in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >
Attachment:
revert2.diff
Description: /
