Created attachment 114161 [details] Text output from "scan uk-SandyHeath" Whilst trying to get a mythtv backend running on a fresh install of Ubuntu Server 12.04.3 LTS (3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 2013 i686 i686 i386) I encountered a strange problem with my Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity. I don't believe the problem is directly Mythtv related, because of the following odd behaviour with both scan and tzap: With scan, I am using the following file, that works on other PCs, for Sandy Heath: T 522000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 498000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE T 714000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE T 722000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE T 690000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE Using this, I get the attached output. This shows a number of key things: 1) It claims to be receiving the same set of channels from the first two Muxes that it tries, even though they should be completely different. 2) The channels from a single mux always stay together, even if they're reported at the wrong frequency. This could be explained by 'scan' believing it has successfully requested a change, even if the hardware hasn't made the change. 3) The first mux it tries to receive after changing from FEC_2_3 to FEC_3_4 gets nothing. The last of these becomes even more apparent when using tzap and a channels.conf file created using a PC that works correctly. When tzap is used to select a channel on a different multiplex to the one previously, the first time it does not lock properly. However, second time it does: rob@minimyth:~/DVB$ tzap -c channels.conf "BBC ONE" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 522000000 Hz video pid 0x0065, audio pid 0x0066 status 0a | signal ffff | snr 00de | ber 001fffff | unc 00000000 | status 1a | signal ffff | snr 0106 | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 00f0 | ber 001fffff | unc 00000006 | FE_HAS_LOCK status 1a | signal ffff | snr 00f0 | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 00f3 | ber 001fffff | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "BBC ONE" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 522000000 Hz video pid 0x0065, audio pid 0x0066 status 0f | signal 6a60 | snr 00c3 | ber 001fffff | unc 00000000 | status 1f | signal 6a7b | snr 00f6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a84 | snr 00f3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a82 | snr 00ef | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6aa2 | snr 00f9 | ber 00000000 | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "ITV3" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 714000000 Hz video pid 0x1ae1, audio pid 0x1ae2 status 1b | signal 6a7e | snr 00dc | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1b | signal 6aec | snr 00ef | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1b | signal 6aef | snr 00fd | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1b | signal 6a7f | snr 00fd | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1b | signal 6a7b | snr 00ee | ber 001fffff | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "ITV3" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 714000000 Hz video pid 0x1ae1, audio pid 0x1ae2 status 0e | signal ffff | snr 00e7 | ber 001fffff | unc 00000000 | status 1e | signal ffff | snr 00fa | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00f7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00f4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00fd | ber 00000000 | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "ITV3" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 714000000 Hz video pid 0x1ae1, audio pid 0x1ae2 status 0e | signal ffff | snr 00ce | ber 001fffff | unc 00000000 | status 1e | signal ffff | snr 0105 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00fd | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00fb | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1e | signal ffff | snr 00ff | ber 00000000 | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "BBC ONE" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 522000000 Hz video pid 0x0065, audio pid 0x0066 status 1a | signal ffff | snr 00eb | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 00fc | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 0103 | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 0105 | ber 001fffff | unc 00000000 | FE_HAS_LOCK status 1a | signal ffff | snr 0103 | ber 001fffff | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "BBC ONE" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 522000000 Hz video pid 0x0065, audio pid 0x0066 status 0f | signal 6a82 | snr 00cf | ber 001fffff | unc 00000000 | status 1f | signal 6a7a | snr 00ef | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a7d | snr 00f5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a81 | snr 00e9 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a80 | snr 00ed | ber 00000000 | unc 00000000 | FE_HAS_LOCK ^C rob@minimyth:~/DVB$ tzap -c channels.conf "BBC ONE" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 522000000 Hz video pid 0x0065, audio pid 0x0066 status 0b | signal 6a70 | snr 00d0 | ber 001fffff | unc 00000000 | status 1f | signal 6a7b | snr 00ef | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a7f | snr 00f0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a81 | snr 00ee | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a86 | snr 00fc | ber 00000000 | unc 00000000 | FE_HAS_LOCK ^C The problem doesn't occur when switching between ever mux. So, for example, immediatley after the "BBC ONE" above, switching to FILM4 works without problems: rob@minimyth:~/DVB$ tzap -c channels.conf "FILM4" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' tuning to 498000000 Hz video pid 0x05dd, audio pid 0x05de status 0f | signal 69fa | snr 00e1 | ber 001fffff | unc 0000001e | status 1f | signal 6a70 | snr 00f8 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 6a09 | snr 00ed | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 69fd | snr 00f5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal 69fd | snr 00f7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK The only trend I have managed to find so far, is that the problem occurs when switching between the muxes with FEC 2/3 (BBCA/D3+4) and FEC 3/4 (SDN/ArqA/ArqB). I found http://code.mythtv.org/trac/ticket/11403 which looked as though it could be related, but having built and installed the latest v4l from git, the problem still seems to remain. Discussing this on IRQ, it was suggested to try http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/ However, the problem still remained using 3.12.0-031200-generic #201311071835 SMP Thu Nov 7 23:45:58 UTC 2013. I have tried the Mythbuntu 12.04.3 as a live 'CD' on both this PC, and other PCs that have worked reliable with this tuner on older versions of Mythbuntu, and every PC shows the same problem. Whilst running either scan or tzap no messages appear in dmesg, so I'm not sure where else I should be looking to understand what might be happening?
Created attachment 114171 [details] Mythtv Scanning - first signs that something wasn't right! When mythtv was scanning for channels, it claimed to have found identical muxes on adjacent channels. eg C48 is a valid mux but C49 isn't. However, it just seems to be reporting what it found on C48 again. C51 and C52 are both valid muxes, but they should have different numbers of channels, and C53 is not a valid mux (but it appears to show the number of channels that would be expected on C52).
Created attachment 143481 [details] Tuning outputs by kernel I think I have encountered this same issue with Hauppauge Nova-TD stick. It fails to tune channels correctly in Linux kernel 3.8.13 and later, but works fine in kernel 3.2.61 (haven't tested with all versions between). Tuning fails in Mythtv and Kaffeine equally. For reference I attach dmesg file of my current Ubuntu running kernel 3.13 and verbose w_scan outputs from 3 kernel versions mentioned above. Two outputs from current kernel show consistent failure within that kernel, while the output from 3.8.13 is slightly different but equally failed compared to output from 3.2.61 kernel where the channels are all correct. The failed tuning result lists some channels to frequencies of other channels, thus making the Hauppauge Nova-TD Stick/Elgato Eye-TV Diversity adapter quite useless under recent Linux kernels. I see here some similarity to Bug 57731.
I experience same problem with the Hauppauge Nova-TD. From my limited testing it appears to affect most/all kernels above 3.2.x.x. The problem is the same in Kaffeine and MeTV. In contrast, the 'Sony PS3 Play TV' device works fine with the latest kernels (notably using the same dib0700 driver as the Nova-TD). As I use my Nova TD daily I'm presently stuck on an old 3.2 kernel distro, can't update unless I find a fix or I buy a new tuner. Spoke to Hauppauge, they confirmed my device is otherwise working ok, advised kernel patch required.