I am seeing a major drop in reception quality on my Hauppauge HVR-950q between 2.6.29.4 and 2.6.30. I know that DTV reception can be finicky at times, however this very much seems to be a driver issue. On kernels 2.6.29.4 and earlier, I have no problem getting in a local VHF DTV station (WTNH-DT). After booting to 2.6.30, the station is unwatchable. I get little to no picture at all using mythtv under 2.6.30, whereas mythtv has no issues with the signal on 2.6.29.4 and earlier. This is entirely reproducable on my end. I can boot into 2.6.29.4 and get a perfect picture, then reboot into 2.6.30 and get terrible reception, boot into 2.6.29.4 and it works great, boot into 2.6.30 and get terrible reception again. This is all within a 10 minute period, clear weather and not touching the antenna. I also have Windows on this machine and the Hauppauge signal strength monitor reports a very high signal to noise ratio and no errors on WTNH-DT. I also have a em28xx based Hauppauge HVR-950 plugged into this machine. It works just fine on both 2.6.29.4 and 2.6.30.
Created attachment 21898 [details] my dmesg under 2.6.29.4
Created attachment 21899 [details] my dmesg under 2.6.30
djh - I will do some testing and see if I can reproduce this locally. If so, I can bisect the tree and see when this actually got introduced.
Jim, Could you please run azap to tune to the station with both kernels, and post the output? This will let me see the SNR data, which will help narrow down whether the problem is with the programming of the demodulator and tuner or whether it's an issue with the bridge. Thanks, Devin
djh - I've just reviewed the dmesg output Jim provided, and the situation looks very strange. In both cases it would appear that the hvr-950q is never actually used to do the tuning. I see ATSC tuning requests for the hvr-950 (em28xx), but not for the 950q. Look at the logs: The 2.6.29 shows both devices being initialized, and the firmware loading for the xc5000. Then it shows a tuning attempt for the xc3028, which is for the hvr-950, *not* the hvr-950q The 2.6.30 log again shows both devices being initialized, and the xc5000 firmware being loaded during analog initialization. Then again we see the tuning attempt with the xc2028 driver. Can you please remove the em28xx based HVR-950 from the product, retest, and provide dmesg output for the condition with only the HVR-950Q present in the system?
Created attachment 22059 [details] azap output under 2.6.29.4 with both au0828 and em28xx attached
Created attachment 22060 [details] azap output under 2.6.30 with both au0828 and em28xx attached
djh - Looking at the two attachments, each only has a single invocation of azap. In fact, it looks like the first attachment has an azap against the 950q and the second attachment has an azap against the 950.
Created attachment 22061 [details] azap output under 2.6.30 only au0828 attached
Created attachment 22062 [details] dmesg under 2.6.30 only au0828 attached
Is there a way to tell which adapter is assigned to which /dev/dvb/adapterX device? If so I can test and let you know if the au0828 and em28xx are assigned different device names under 2.6.29.4 and 2.6.30. I'm running "azap -a 0 WTNH-DT" for all of the tests I've done today.
djh - the SNR stats actually look a little better with the 2.6.30 code. The SNR floats at around 0xdc/0xe6 with 2.6.29 and 0xf0/0xfa with 2.6.30. Still, there shouldn't be any changes to the SNR behavior in 2.6.30, since the xc5000 improvements didn't come until 2.6.31.
djh - Jim, if you have femon installed, you can run that and it will tell you the frontend. e.g.: root@ubuntumb:~# femon -a 0 FE: Auvitek AU8522 QAM/8VSB Frontend (ATSC) status | signal 00fa | snr 00fa | ber 00000000 | unc 00000000 | status | signal 00fa | snr 00fa | ber 00000000 | unc 00000000 | ^C
Yep, the em28xx and au0828 simply switched device names between 2.6.29.4 and 2.6.30. Strange, I thought udev took care of consistently naming devices. So it looks like this is just a user error. Sorry for the false alarm, feel free to close the bug.
djh - that isn't terribly surprising. With the addition of the HVR-950q analog support, the driver takes longer to initialize, so the HVR-950 wins the race to creating the DVB device object. Not much I can do about that I'm afraid.
djh - This was confirmed to be user error and *not* a regression, so this ticket should be closed (I'm mentioning this because it was just made a blocker for 2.6.29)
Dropping from the list of regressions, closing.