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.
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.
Hi Per,
thanks for this. I had the same problem and now it’s working.
jakommo
jakommo said this on October 13th, 2012 at 14:57
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 🙂
Louis Tim Larsen said this on October 16th, 2012 at 18:36
@Jakommo, @Louis: Glad you got it working too 🙂
Per said this on October 16th, 2012 at 18:40
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?
Louis Tim Larsen said this on October 16th, 2012 at 19:01
@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.
Per said this on October 16th, 2012 at 19:51
Well. Just changed the modulation from “Auto” to “64 QAM” during a scan in mythtv. Now I find all channels at once.
Louis Tim Larsen said this on October 16th, 2012 at 21:08
@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).
Per said this on October 16th, 2012 at 21:12
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?
Louis Tim Larsen said this on October 25th, 2012 at 20:18
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.
Per said this on October 25th, 2012 at 20:54
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.
Louis Tim Larsen said this on October 25th, 2012 at 22:25
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.
Louis Tim Larsen said this on October 28th, 2012 at 12:16
@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]
Per said this on October 28th, 2012 at 16:02
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.
Louis Tim Larsen said this on January 21st, 2013 at 16:04
A new stable version of the HDHomerun firmware and software have been released: https://www.silicondust.com/support/hdhomerun/downloads/
😉
Louis Tim Larsen said this on February 11th, 2013 at 18:59
Thanks for the update!
Per said this on February 12th, 2013 at 11:26
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?
Supremebot said this on March 3rd, 2013 at 12:27
@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.
Per said this on March 4th, 2013 at 20:30
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
Mike said this on March 17th, 2013 at 16:46
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
Kenni said this on March 28th, 2013 at 9:05
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?
Per said this on March 28th, 2013 at 10:15
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 🙂
Kenni said this on March 28th, 2013 at 13:11
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/
Kenni said this on March 29th, 2013 at 11:04
@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!
Per said this on March 29th, 2013 at 11:13
@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 🙂
Per said this on March 29th, 2013 at 11:14