Talk:Hauppauge WinTV-NOVA-T-500

I bought a Nova-T-500 from PC World in Croydon on 2nd August 2007. Below the barcode on the box, it reads "WinTV-NOVA-T-500 model 289 SL-289-V2.1-UK". It would appear that having V2.1 on the box could be either the Nova-T or the Nova-TD. Most confusing!

If anyone's interested, PC World had about five Nova-T cards in stock when I bought mine. None of them had the Diversity sticker on them. --Nickg 00:32, 4 August 2007

Confusing indeed! Thanks for the info. I'll copy the relevant portions over to the article. --CityK 17:53, 4 August 2007 (CEST)

Is there any reason why LNA isn't enabled by default? Surely the vast majority of users would want it on. --[Chris Simmons]

Card Identification Confusion Continues

Continuing time traveler Simon Kenyon's 2009-01-07 article comment in the 1.3 WinTV-NOVA-TD-500 section: I, too, spoke with Hauppauge UK Technical Support today (06-JAN-2009). According to the technical support agent, the WinTV-NOVA-T-500 (presumably all revisions including the 289 SL-289-V2.0-UK and 289 SL-289-V2.1-UK) is superseded by the WINTV-NOVA-TD500 (their ONLY current production model of the DVB-T Dual-Tuner PCI card.)

The Hauppauge tech support agent also stated the WINTV-NOVA-TD500 is using a DiBcom controller (though it is unclear if this is the same problematic DiB0710 controller as used in 289 SL-289-V2.1-UK cards.) Hopefully someone with direct experience can expand the collective knowledge by sharing here.

Lastly to underscore Simon Kenyon's article comment, Hauppage will NOT exchange the Rev. 289 SL-289-V2.1-UK card or the new WINTV-NOVA-TD500 for a Rev. 289 SL-289-V2.0-UK card; Hauppage directs unhappy consumers to return products to the place of purchase for a refund, which is the permissible and correct action under UK law. Would it be possible to strike-through or redact the two incorrect sentences in the article 1.3 WinTV-NOVA-TD-500 section which begin with "Fortunately, for Linux users..."?

You mean like that :D ... go nuts, its a wiki! --CityK 03:11, 8 January 2009 (CET)

Jittery exception not limited to Australia

I seem to be experiencing the same issue with occasional jittery reception, but I live pretty far from Australia. A fair amount of my recordings (approx. 20% maybe more) suffers from visual and sound artifacts. I live in Denmark and receive channels at 8 MHz. I will try the fix (buggy_sfn_workaround) and see if it fixes my problem. I will report my findings once I have recorded some shows. --Cthulhu 08:47, 8 January 2009 (CET)

UPDATE: Unfortunately buggy_sfn_workaround didn't alleviate my problem, as the very first recording after adding the option (and rebooting ofc) still showed the artifacts. I guess my problem lies elsewhere. Any suggestions? --Cthulhu 15:19, 12 January 2009 (CET)

UPDATE 2: After having a look at the involved kernel modules, I noticed that both dib3000mc and dib7000p has the buggy_sfn_workaround option. I have now tried enabling it for both and so far it's looking good. I have recorded 6 shows so far without artifacts. --Cthulhu 11:36, 5 February 2009 (CET)

UPDATE 3: I'm happy to report, that I haven't had a single recording go bad since adding the buggy_sfn_workaround option to both kernel modules. I therefore consider my problem fixed. I hope this will help others with the same problem. --Cthulhu 15:47, 23 March 2009 (CET)

---

29/Mar/09 - Hi, I live in the UK and have just bought this card and I'm using it to watch TV under MythTV but have quite a bad jittery picture. Would it be possible to describe the solution in a little more detail. For example the "/etc/modprobe.d/options" file doesn't exist in Ubuntu and if I create it and add "options dib3000mc buggy_sfn_workaround=1" and reboot the problem is not solved. It would be great if you could shed some light on what commands you ran to fix this issue. Much appreciated.