Call for Testers: HVR-1300, HVR-3000, HVR-4000 DVB-T tuning fix

For quite some time, there have been users complaining of DVB-T scanning problems using application such as MythTV or w_scan. Even stranger, they claimed that using /usr/bin/scan would indeed work as expected.

For example, this Launchpad ticket has tracked the issue for almost two years:

https://bugs.launchpad.net/mythtv/+bug/439163/

MythTV has a ticket tracking the issue too (although closed due to it being declared “upstream”):

http://code.mythtv.org/trac/ticket/9270
http://www.mythtvtalk.com/hvr-4000-fails-scan-11318/

I finally got my hands on some hardware to test with, and what I found was not a device specific bug, but rather a race condition in the framework. This will actually effect far more devices than just the three noted above. Pretty much any card which strobes the reset pin in it’s ts_ctrl() function will hit this issue with applications like MythTV.

I’ve cooked up a patch for the issue and submitted it to the linux-media mailing list for upstream inclusion. It can also be found here if users want to apply it directly to a media_build tree themselves:

https://launchpadlibrarian.net/74557311/frontend_dvb_init.patch

My hope is that this should fix a longstanding issue where no developer had the time to investigate. I’ve tested it with my DVB-T generator and now I can see that w_scan does work. But it would be great it some users would try it out and report back as to whether it improves their situations. Feedback in the comments section welcome below….

17 thoughts on “Call for Testers: HVR-1300, HVR-3000, HVR-4000 DVB-T tuning fix

    • Devin Heitmueller

      Hello Tor,

      It is unlikely that the fix above has any real bearing on the Nova-T 500. The Nova-T 500 issues are related to suspend/resume and soft reboot, neither of which are tied to the problems seen above.

      Cheers,

      Devin

  1. I wanted to test this but cant get the media_build build on my ubuntu oneiric with kernel 3.0
    Maybe there is some trouble with the build script and the new kernel versioning. Will try it as soon as i know how to get this compiled. Will try it on an 2.6.39 kernel anyways

  2. Devin, thanks a bunch for finding this!

    Now that the problem is understood does it make sense to add a sleep after the close or before the open in MythTV to help those with a pre-fix kernel? If so how long should that sleep be? 50 ms? 100 ms?

  3. Hi Devin.

    Congratulations Devin on locating this bug and lets
    hope this solves the issue for the many interested users.
    I am sure your effort is much appreciated, thank you.

    darron

    • Devin Heitmueller

      Hi Darron,

      Yeah, it was one of those cases where it was just a matter of getting a few hours to debug the issue. On a related note, I especially like your “derived schematic” for the HVR-4000 on your website. I’ll have to put a comment block into the driver containing the actual GPIO map which should help others in the future (and avoid the sort of reverse engineering you were compelled to do).

      It would be useful if you could please try the patch, and if it works for you then send a “Tested-By” reply to the post on the linux-media mailing list.

      Devin

      • Hi

        I will see about testing the hvr1300 this week some time.
        the actual commit that raised this fault (gpio setup) was
        AFAIR done to correct a different issue switching between
        MPEG encoder and DVB-T on that device. Hopefully
        everything now works as expected.

        For the GPIOs themselves, I do have a bunch of old
        patches for the hvr1300 which includes the following
        for example:
        http://hg.kewl.org/pub/v4l-dvb-20100517/rev/b2c126d4f749

        There is similar detail for the hvr4000 already elsewhere
        but it’s been so long since I even looked at DVB on
        Linux it’s quite hard to remember.

        If you are on a mission then there is still an outstanding
        issue with the ISL LNB controller on the hvr/nova-s
        which is always setup without short circuit protection.
        The datasheet specifically says the protection ought
        to be off only when tuning and turned back on otherwise.
        That was needed for some stubborn external switches btw.

        I am no doubt boring you any readers now, sorry!

        All the best.
        Bye!!!
        PS. Thanks for the comment about the schematic.

    • Devin Heitmueller

      Hello Scirocco,

      If you are unfamiliar with applying patches to your kernel, your best bet is probably to wait until your distribution vendor releases an updated kernel containing the fix.

      You can also try to appeal to the #linuxtv IRC channel on freenode, and perhaps somebody there would be willing to help walk you through the process…

      Regards,

      Devin

    • Devin Heitmueller

      Hi John,

      The kernel fix has already been submitted to Linus for upstream inclusion in 3.0.0 (Mauro sent the pull request on July 16th). For some reason though, the patch wasn’t merged into the linux_media tree yet, which is something I emailed Mauro about this morning.

      Regarding the relationship between my patch and Daniel’s: Daniel’s patch is a workaround which puts a slight delay between tuning attempts to avoid the race condition. It is not the preferred fix, but may be good enough for people who cannot upgrade their kernel for some reason.

      Devin

Leave a Reply