Even more HVR-950q fixes….

Continued debugging has produced another dozen fixes for the HVR-950q. Most of these are low-probability failure conditions (race conditions, etc). However take a bunch of 1/1000 chance items together and you’re likely to hit one of them once in a while…

A couple of noteworthy changes:

  • Firmware load time has been sped up to 2.9 seconds (down from 8-10 seconds). This should eliminate the need for MythTV users to specify the “no_poweoff” xc5000 modprobe since it will now load fast enough to avoid a mythfrontend timeout.
  • Fix a case where the xc5000 tuner enters a failure state and all subsequent tuning requests fail until the device is reset.
  • Minor speedup in switching from analog to digital mode and vice-versa.
  • The git tree is the same as the previous post – I’ve just added more patches to the end of the series:

    http://git.kernellabs.com/?p=dheitmueller/cx23885_fixes.git;a=shortlog;h=refs/heads/950q_fixes

    Comments/feedback welcome, as always.

6 thoughts on “Even more HVR-950q fixes….

  1. I have a comment, more like a question. How can I download these fixes, then integrate that in my current ubuntu distro ? Because I really want my hauppauge 950q to be as good as it could be (windows users beware) especially with the XBMC media center. That xbmc program is so great… I won’t need windows anymore if the xc5000 module driver works all the time.

    • Devin Heitmueller

      Hello Joel,

      I will hopefully be submitting the patches upstream this weekend. Once they are merged, you can follow the standard “media_build” procedure described on the linuxtv.org wiki in order to update your system.

      Regards,

      Devin

  2. I think i got all the bugs you described in your blog… I tried Linux mint 11, 13, Ubuntu 12.04, Peppermint OS, XBMCbuntu, changed the kernel a few times…

    The only thing I’ve done that worked was to blacklist the module from loading, then load the xc5000 first, then load the au8522 sound module later …. and then i found another problem and wiped the partition clean to reinstall linux and hit the bugs again.

    I am the owner of a Acer Laptop that supports 1080p only in hardware decoding.
    It has a 64 bit dual-core cpu and also the graphics on the same chip, from AMD (ati), 1ghz dual-core. AMD C50 Fusion apu. Graphics model : Radeon 6310 (directx 11 compatible)
    250gb hard drive 7200 rpm, 3gb ddr3, dvd burner, 15 inches screen, 34watts power consumption + usb accessories…

    10 usb addons on 3 usb powered hubs, only 1 wire on the computer.

    Bluetooth dongle, wireless mouse, wireless keyboard, wireless remote that emulates a full keyboard & mouse, usb sound card, usb tv tuner hauppauge 950q, usb printer from hp all-in-one 3050a.

  3. Hi Devin – I built this tree and was able to boot without getting the ““Device not found” error when not using no_poweroff=1. You mention a fix no longer requiring that option to work around a mythtv timeout, and I assume that may have helped this too. Anyway, seems great so far and I’m really looking forward to updating my system with these fixes full-time – tuning is so much better. Thanks tons!

  4. I am running Fedora 18. I have a 950Q on my backend along with an old PVR-150 for analog recordings and the IR-blaster. The 950Q used to misbehave on startup, but that hasn’t been an issue for a quite a while now. I suspect that was when the Fedora kernel versions caught up to the level where your patches were submitted. I think that was around version 3.7, and Fedora 18 is at around 3.9.9 at the time of this posting.

    However, I still see cases that seem a lot like your second bullet point above. Myth will attempt to record something and fail, showing a recording entry with no file size. After that failed recording typically all subsequent recordings will fail. I’ve found that restarting the mythbackend process sometimes fixes the issue. Or I have had some success with stopping the mythbackend, using azap to tune a channel, and then, starting the backend again. Sometimes I just have to do a full restart. While this happens too often for my liking in Myth, I haven’t had it happen to me using azap for manual tunings as best I can remember.

    I haven’t been using the no_poweroff switch on the xc5000 module load for a while. I started playing with it today just to see if there was any perceivable difference. The only thing I’ve noticed so far is that when the mythbackend process starts or is restarted, I see the following in dmesg three times …

    [ 1291.315355] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)…
    [ 1291.315402] xc5000: firmware read 12401 bytes.
    [ 1291.315404] xc5000: firmware uploading…
    [ 1292.481371] xc5000: firmware upload complete…

    If I have no_poweroff=1, it only shows up once during the mythbackend startup and not again on a restart. I also only see it once when I use azap. I am not sure it is relevant.

    Do you have any recommendations for the capture card setup for a 950Q, the digital part? I’ve noticed there is a timeout of 3000 ms by default, but there is also a 500 ms signal timeout on the first page. Under recording options there is a tuning delay, which is 0 by default. I have had “Open DVB card on demand” unchecked up till now, but have been wondering if I should check that option.

    Any advice is appreciated. Thanks,
    Michael

  5. After a recent change in my configuration, the tuner has worked for several days without a glitch. Glitch meaning a recording that stopped prematurely or never started. Long story short, I think the issues was my USB interface rather than the 950Q itself. Now, here is the long story too.

    I bought a new motherboard a few months back, and it was after that when I started seeing issues again. The issues were similar enough to the old known issues that I assumed it was the tuner. However, I also had the 950Q plugged into a USB 3.0 plug on this new motherboard. I’m not sure how the 950Q deals with USB 3.0. I know USB, PCI-E, SAS, SATA, etc. are specified to be backwards compatible generally. So, I don’t really suspect the USB 3.0 interface to be the problem. I did notice that while the jacks clearly indicate those plugs as USB 3.0 (blue plug), the kernel sees them as USB 2.0 (determined by lsusb -v). Now, I wonder if there is some driver issue on the USB side that is causing dropped packets or something else.

    My solution was to put the 950Q on a USB 2.0 interface that was clearly indicating 2.0 both by plug color and lsusb -v. That seems to have done the trick–unless I just jinxed it. Of course, Fedora updated to MythTV 0.27 around about the same time. I think the issues were still occurring even after 0.27 installed though.

Leave a Reply