Red Hat Bugzilla – Bug 841225
Hauppauge 950Q won't tune reliably
Last modified: 2013-07-04 18:59:43 EDT
Using Fedora 17 and kernel 3.4.4
Since kernel 3.4.x, I have not been able to get my Hauppauge 950Q to tune reliably using either VLC, smplayer, or w_scan. I presume that other DVB applications would fail similarly. VLC is the easiest for me to demonstrate problems with this tuner.
This happens often, but not every time.
Steps to reproduce:
1. Open VLC
2. Open a terminal, and run: watch "dmesg -T | tail -20"
2. Open the channels.conf file from VLC.
3. Select a channel
THe channel begins to play, and continues to play for as long as it is selected.
Sometimes, there will be no problem, and I will receive the expected results.
Sometimes, if I select a channel in VLC and the channel begins to play, sometimes it ceases to play within 30 minutes. This isn't an issue of poor reception. VLC will display the last frame decoded. No other channel can be selected.
The following messages appear in dmesg while VLC attempts to tune a channel:
Jul 3 10:17:31 ace kernel: [ 453.011678] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
Jul 3 10:17:31 ace kernel: [ 453.012216] xc5000: firmware uploading...
Jul 3 10:17:39 ace kernel: [ 460.258012] xc5000: firmware upload complete...
Jul 3 10:18:00 ace kernel: [ 481.942916] au8522_readreg: readreg error (ret == -5)
Jul 3 10:20:35 ace kernel: [ 636.934494] au8522_readreg: readreg error (ret == -5)
Jul 3 10:21:08 ace kernel: [ 670.065867] au8522_readreg: readreg error (ret == -5)
Jul 3 10:24:02 ace kernel: [ 843.653620] au8522_readreg: readreg error (ret == -5)
If I close VLC, then repeat the steps to reproduce, the following messages appear in dmesg:
Jul 3 10:32:04 ace kernel: [ 1325.724170] xc5000: I2C read failed
Jul 3 10:32:04 ace kernel: [ 1325.724174] xc5000: Unable to initialise tuner
Jul 3 10:32:07 ace kernel: [ 1329.023788] xc5000: I2C read failed
Jul 3 10:32:07 ace kernel: [ 1329.023792] xc5000: xc_SetTVStandard failed
If I then attempt to change a channel in VLC, the following appears in dmesg:
au8522_writereg: writereg error (reg == 0x8081, val == 0x00c4, ret == -5)
There are a series of fixes for this board at:
The patches are under testing and the developer should be submitting me soon a pull request for this series.
3.4.11-1 fc16 kernel.
mythtv box is plagued by:
[20259.772884] au8522_readreg: readreg error (ret == -5)
Actual Results: mythtv recordings are incomplete.
The only errors are the readreg errors.
A monk recording scheduled for 2 hours only recorded 29 minutes starting at 20:00. There is a au58522_readreg error at 20:28:30.
Oct 19 20:28:30 mythtv kernel: [20259.772884] au8522_readreg: readreg error (ret == -5)
I added 22 of the 24 patches (patch 12 and 22 seem mostly applied already except that some of the code in 3.4.11-1 was not as it is in mainline, so these were the two not applied) from the Aug 7th batch including https://patchwork.kernel.org/patch/1282501/
After applying the patches things are better than before, but the au8522_readreg error persists. It's better because the system boots with mythbackend autostarting and can tune without doing resets of the HVR950Q (via echo to usb device's authorized node.) Prior to application of the xc5000 patchset, the tuner would never tune without post boot resets. (Sometimes multiple resets.) Plus, after tuning channels that don't come in all of the time, the tuner doesn't lock up like it did before the patchset was applied.
Does anyone have a newer kernel with all of the latest xc5000 patch set, who had this problem before, not experience this problem any longer?
Are there still issues being seen with the 3.7.3-101 kernel update in updates-testing? This bug is a bit stale at this point.
This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks. If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.