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)

----

TFotherby 29 March 2009 - 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.

----

I use Gentoo so I'm not too familiar with Ubuntu. However I do have access to an Ubuntu machine and it does indeed have the /etc/modprobe.d/options, so I'm a bit puzzled why you don't have it. Try adding these 3 files to /etc/modprobe.d:

dib3000mc:

options dib3000mc buggy_sfn_workaround=1

dib7000p:

options dib7000p buggy_sfn_workaround=1

dvb_usb_dib0700:

options dvb_usb_dib0700 force-lna-activation=1

And reboot.

I take it that you have all dvb drivers compiled as modules. I believe this is default in Ubuntu, so you probably do. You can check that the changes was applied with:

cat /sys/module/dib3000mc/parameters/buggy_sfn_workaround

cat /sys/module/dib7000p/parameters/buggy_sfn_workaround

cat /sys/module/dvb_usb_dib0700/parameters/force-lna-activation

I hope this helps. If not try posting the output of lsmod. --Cthulhu 11:34, 30 March 2009 (CEST)

----

TFotherby 30 March 2009 - Thanks I appreciate you getting back to me. I tried setting these parameters and checked they were activated but had no luck - mythtv picture was still suffering from tearing and noise glitches. I think something is wrong at a more basic level - My TV signal strength doesn't get over about 56% and I get different results depending on what socket I plug the coaxial cable into. If I plug it into the bottom input (the one closest to the IR port) I seem to get a slightly better signal on one tuner but zero-signal on the other but if I plug it into the top input I get equally poor signal on both tuners. I know there isn't a issue with the cable because the signal is fine when plugged into the TV so I'm wondering whether I have a faulty Nova-td 500 card? I tried other DVB methods and had no luck with Xine or Kaffine. I did have to take the backing plate off the card because my case only has low profile PCI slots but I used electrical tape to make sure the metal of the card inputs didn't touch the metal of the case. Still - there seems to be some kind of feedback or noise being introduced?

An important note about *warm* rebooting with this card - it can cause problems!

I'm using Fedora 15 x86_64 and Mythtv 0.24

I had a frustrating few hours last weekend trying to get the remote to work with this card and LIRC. Frustrating because the card would work, I'd go and edit a few innocent paramaters (like, say my .lircrc file, or the channel list) do a reboot and... Hey the remote had stopped working. As you can imagine I was changing things and changing them back until I went blue. Turns out that the card seems to have some functionality issues on a warm reboot - the firmware doesn't reload properly or something. Some reports of the card not working *at all* after a warm reboot, so my problem was relatively minor! All works fine when the machine is totally powered off then turned on again, and yes, knowing that I'd wholeheartedly recommend this card.

A much more minor issue was that the rc-keymap file that ships with the kernel (now lirc is - kind of merged with the kernel - was wrong for my remote. Check this link if you're having problems: [1]