HDHomeRun and MythTV 0.25

After having run the previous version of MythTV for a couple of years without any significant issues, I upgraded to MythTV 0.25.

That broke a few thing, one of which I initially didn’t want to spend time on fixing for now: My existing grabber card sometimes locked up when starting a recording, preventing the box from shutting down, and it didn’t record any of the scheduled recordings either. I thought this could be related to a bug in an updated driver, so I decided to test out a HDHomeRun setup instead. As for saving time, that turned out to be a bad idea! But in terms of getting to a working solution, it looks as if I eventually got to a working solution… read on below.

To make a long story short: It didn’t work as expected.

Initially, all recordings and live tv had glitches in the video and audiostreams, with various error messages being logged. It was not only the shown audio; the recorded files also had glitches and reported errors when played with e.g. VLC on the same or on other machines.

The errors I saw in the mythfrontend.log and mythbackend.log files (in /var/log/mythtv) could be traces like e.g.:

I HDHRStreamHandler ... <RecordingQuality ... 
countinuity_error_count="2234" packet_count="1739249"> ...

showing a high amount of discontinuities (if I got that right), or some sequences of interleaved message like e.g.:

E Decoder avformatdecoder.cpp:4216 
(ProcessAudioPacket) AFD: Unknown audio decoding error
N CoreContext mythplayer.cpp:2078 (PrebufferEnoughFrames) 
Player(0): Waited ... ms for video buffers ...

I also noted strange issues when doing the initial channel scans, which made me a bit suspicious initially: The signal strength is reported by MythTV to be only 49%(!), but at the same time — i.e. during the scan — a running HDHomeRun config GUI shows that each of channels sync perfectly and have 100% signal strength and quality (in my case I have a strong signal; I can get it to 97% if I move the box to the cable drop furthest away in the house). And in MythTV during live tv, it typically shows around 50% signal strength only — with HDHomeRun config GUI again showing 100% signal.

So I tested a bunch of stuff, including disabling EIT which I had suspected, to no avail. I eventually gave up, and I currently believe there is a problem with the way MythTV is interfacing to the HDHomeRun in at least 0.25. There are all sorts of suggestions on the net to fix or circumvent similar issues (increase buffer sizes, have a ping running to prevent some ARP messages, etc), but none worked for me. The problem is not related to the network. In fact, the HDHomeRun box works very well when using it from e.g. VLC from the same machine, and I have no dropped packages when looking at the network interfaces on the box.

But there is a workaround that will allow MythTV 0.25 to work with HDHomeRun!

Just install the kernel drivers for HDHomeRun (I used Villy Thomsens dvbhdhomerun ppa; install dvbhdhomerun-dkms and dvbhdhomerun-utils and/or have a look here), and install your HDHomeRun box as a  DVB card instead of as a decidated MythTV HDHomeRun box. This will cause MythTV to use the dvbhdhomerun kernel drivers instead of relying on  MythTV’s built-in support. I have not yet seen any detrimental effect of doing so — and now it all seems to work :-)

There is a description on how to do this on the silicondust site, but it is somewhat incorrect (use the ppa instead also for newer releases, and you don’t need to edit the dvbhomerun-utils.conf file), so have an eye on what you do!

The gist of the installation is to enable the ppa, install the dkms drivers, edit the /etc/dvbhdhomerun setup file to point to your HDHomeRun box and define its type, add a line to /etc/modules (or similar) and set up a DVB card pointing to the right adapter. That’s it — then you can do your channel scans as needed. If you are not familiar with Linux, then you might need a little more detailed instructions than below, though. Feel free to ask here also.

But in essense, you need to type in the following commands (if you’re using e.g. Ubuntu 12.04):

sudo add-apt-repository ppa:tfylliv/dvbhdhomerun 
sudo apt-get update 
sudo apt-get install dvbhdhomerun-dkms dvbhdhomerun-utils

Then ensure you add a line like follows at the end of the /etc/modules file:

dvb_hdhomerun

And edit the /etc/dvbhdhomerun file to suit your setup. Mine looks like this (replace the FFFFFFFF with the number of your box):

[FFFFFFFF-0]
tuner_type=DVB-C
use_full_name=true
[FFFFFFFF-1]
tuner_type=DVB-C
use_full_name=true

The you may reboot and install a new DVB card in MythTV and select the appropriate /dev/dvb/adapterN/frontend0 file(s).

So far, this seems to work for me. I will have to wait and see if this also have the “locking” problem, though, before declaring a total success.

… just wanted to put this here for others that might have similar problems!

For the record, I’m using the latest beta firmware (as of the time of writing): “20120820beta1″. The stock one (201204-something) had problems detecting my channels properly even in the initial scan using the GUI.

 

As a side-note: I noticed that when the MythTV backend runs and has access to the HDHomeRun box, it can cause glitches to other machines also connected to the HDHomeRun box. I haven’t spent a lot of time on this, but it appears not to be related to EIT, though.

24 Responses to “HDHomeRun and MythTV 0.25”

  1. Hi Per,
    thanks for this. I had the same problem and now it’s working.
    jakommo

  2. Hi Per,
    I had big problems with my ATOM mythtv box and live tv and though it was do to underpowered hardware but this guide seems to solve it.
    I can’t thank you enough. I think it’s time to enjoy a guide movie in HD tonight :)

  3. @Jakommo, @Louis: Glad you got it working too :-)

  4. In mythtv I can’t just scan a single frequency like 346000000 and then it’ll find all my channels. I need to scan different frequencies dumped from “hdhomerun_config XXXXXXXX scan 0 kanaler.txt”.
    Do you also need to scan more than one frequency?
    I think that it’s annoying and time consuming cause I can’t just easily update my channel database.
    Would a firmware update to the newest beta solve this?

  5. @Louis: As far as I know, it depends on how your provider sends “adjacent” channel information.

    It is possible to let MythTV scan on one channel, trying to discover multiple other channels which are “referred to” somehow. After having scanned the first one it will attempt to scan those additionally found — but if certain channels are not listed by those already scanned, they will be missing.

    I started with one scan (probably 143.000 MHz), which uncovered a bunch of additional ones (I’m on a YouSee cable network) which were then scanned — but it didn’t find all of them!

    So I did something similar to what you propose; I made a list of all channels in my network and checked which were missing from the initial scan(s). I then scanned those afterwards one by one — which turned out to be a significant portion, unfortunately.

  6. Well. Just changed the modulation from “Auto” to “64 QAM” during a scan in mythtv. Now I find all channels at once.

  7. @Louis: Yes, that was also required here to be able to find anything… but do a check afterwards that all channels are found correctly. I had to enter additional channels here (in particular some of the HD versions that are sent on separate channels).

  8. I still have some small noise at some times. Would it help to upgrade the tuner with beta firmware or updating to MythTV 0.26?

  9. I haven’t tested 0.26 yet.

    However, I’m running the beta firmware on my setup, and that seems to work (my version is 20120820beta1).

    As it might be fast to do a firmware upgrade, I would personally try that first before trying 0.26, and hopefully that would solve your issues.

    Have you checked that you have a good signal? If you signal is marginal, that could also be the source of noise.

  10. My signal is quite good.
    I know that firmware upgrades are a quick thing to do, however it’s not so easy to downgrade if there are big bugs.
    Don’t know if I should use beta firmware or wait for new final release.

  11. i used this trick:

    http://www.silicondust.com/support/hdhomerun/instructions/mythtv/

    Packet loss:
    On slower machines or machines under high load the maximum receive socket buffer size for the system should be increased to 1MB:

    sysctl -w net.core.rmem_max=1048576


    And together with your driver tricks I have had no problems with signal issues.

  12. @Louis: Thanks for reporting back — glad to hear you got your issue solved too ;-) It is a good idea to increase the buffer size for slow’ish/loaded systems, to prevent buffer overruns.

    [I edited the link above to point to the correct page; somehow it got mangled initially]

  13. One last thing I forgot to mention. To make playback absolutely perfect on my ION/ATOM setup I changed “CPU Speed” from low to high in the backend.

  14. A new stable version of the HDHomerun firmware and software have been released: https://www.silicondust.com/support/hdhomerun/downloads/
    ;)

  15. Thanks for the update!

  16. Hej Per

    Thanx for this guide i have same problem with only 50% signal, in TVheadend everything works like i should. So this must be a mythTV problem.

    But i dont understand this “The you may reboot and install a new DVB card in MythTV and select the appropriate /dev/dvb/adapterN/frontend0 file(s).” where should i select that? dont i need to select hdhomerun under adapters?

  17. @Supremebot: Did you get the kernel driver installed on your setup?

    If you did, then you need to get back into mythtv setup and add the new DVB device to your setup. You must select the device (/dev/dvb/adapterN/frontend0) that corresponds to your newly installed driver — it will look like a generic capture card to mythtv, not like a hdhomerun device.

  18. I’m on mythbuntu 12.04. I’m on the 0.26 repos. Something is wrong with the packages as I got errors trying the instructions above. I downloaded the dvbhdhomerun_0.0.15~precise.tar.gz (47.4 KiB) file for precise and followed the build instructions to build from source. I also needed to use DVB-T even though I am on Time Warner Cable in the US (DVB-C will not work). Another point of confusion here. Anyhow, my video glitching appears to be gone so thanks!

    https://launchpad.net/~tfylliv/%2Barchive/dvbhdhomerun/%2Bpackages

  19. Hi Per

    I’ve been looking at the issue and have been in contact with Silicondust. It is a PID filtering performance issue in HDHR, introduced in firmware 20120424beta1 and it affects all firmwares up to and including 20130323beta1.

    Silicondust has released a new beta firmware today, 20130327beta1, which should fix the issue.

    Best regards
    Kenni

  20. Thanks for the update, Kenni.

    Very interesting that this now gets addressed by Silicondust!

    So I take this to mean that with the newest firmware, using the “native” built-in HDHomeRun interface in MythTV should now work as expected and that the workaround above should then no longer be necessary.

    Have you already tested it with the latest firmware?

  21. Correct, the workaround above is not needed with the latest beta firmware (or with the old 20120405 firmware).

    I’ve tested the 20130327beta1 firmware for about one hour this morning, and I was unable to reproduce the issue with this firmware. I’ve been testing 15+ beta firmwares during the past few days and I was able to reproduce the issue on all of them within seconds, so I’m fairly confident that this particular issue has been fixed in the 20130327beta1 firmware :)

  22. FYI, Silicondust has now released a stable (non-beta) version of the firmware which includes the fix (release 20130328):
    http://www.silicondust.com/support/hdhomerun/downloads/

  23. @Mike, your posting got stuck due to the embedded link — but if you read further below, you will see that Silicon Dust apparently have fixed the issue, and a new firmware should make it possible to use the HDHomeRun directly from MythTV “as originally intended”. But I guess if you have a working setup already, then the “if it ain’t broken don’t fix it” might apply :-)

    Thanks for reporting back!

  24. @Kenni, thanks for the quick update, the link and overall your push to get this fixed! Looks like Silicon Dust finally moved fast once they figured out what was wrong :-)