metaruss

So I finally bit the bullet and stood-up a MythTV front end on this Raspberry Pi 4 that had been hanging around the office for years.  I had back-ordered one during the post-COVID supply chain crunch and it turned up many months (possibly more than a year) later, but I hadn’t had the motivation to tackle the project.  The Raspberry 5 announcement reminded me, so I ordered one and decided to try to get Myth working on the RP4 to start.  There are some issues with the decoder and graphics software stacks on the RP5 at the moment, but I knew the RP4 would work.

I started with a degree of ignorance and built it in the same way that my other front ends are setup: using Christian Marillat’s “dmo” packages from deb-multimedia.org and running the front end solo in an auto-login X session.  This worked fine, but I was not getting good performance and could not seem to get the playback profiles setup the way I needed them.  This led me down a rabbit hole; it turns out that a lot of the information in the MythTV Wikis is obsolete and does not apply to modern releases.  For example, the recommendation is to use the OpenMAX decoder but no such decoder exists in MythTV 0.33+.  The V4L2 decoder is there, but it is buggy and tends to lockup sometimes.  The standard decoder drops frames and playback is jerky no matter how I set the read-ahead or fiddle with CPUs.  I even tried overclocking it.

While searching for details, I kept seeing references to “mythtv-light“.  There is not a lot of explanation as to what it really is or why it is needed.  What is so light about it?  The wiki talks about the back end, but very little about the front end.  What build flags are used?  Why is it distributed via a random Google Drive?  It all seemed very sketchy, so I wanted to avoid it.  Eventually I found a separate git repository that contains packaging scripts for MythTV for a variety of platforms.  In there were the scripts for mythtv-light, which seems to focus mainly on making installation as simple as possible from a single package without too many outside dependencies.  It’s not really there to support RPi, necessarily.

That said, in terms of the front end (which is all I care about), the RPi MythTV Light packages seem to enable three main things:

1. QPA EGLFS rendering support.
2. Specific decoder and OpenGL support for the Raspberry Pi.
3. Disabled support for all unnecessary libraries and features.

In terms of overall speed and efficiency, #1 is really important on the Raspberry Pi.  By directly supporting Qt’s EGL platform abstraction layer, there is no need to run X at all.  Christian’s dmo packages do not seem to support this, as they are build against Qt for X.  #2 used to be very important, but that no longer seems to be the case.  I believe this is because the version of ffmpeg that ships with Raspian is already setup to use whatever hardware decoders are currently supported on the RP4.  The “Standard” decoder in Myth uses ffmpeg, so it “just works” without any special support for RPi-specific OpenMAX libraries.  #3 is a nice-to-have, but with 8GB of RAM and X not running I don’t know that is matters so much for the front end on the newer RPi’s.  I am getting very good performance on the RP4 and it can *just about* manage to decode 1080p HEVC with only an occasional skip when the bit rate gets too high.  The CPUs are pretty busy, though.

Proper cooling is a must or the SoC will hit thermal throttling.  The above RP4 that I used as a test bed just has a base plate and a small heat sink on the SoC.  It is not enough: the package temperature quickly rises to 60C under heavy load.  There are a few “brands” that list a passively-cooled case on Amazon like the one pictured on the right (there are versions available for RP4 and RP5).  It comes with thermal pads for all of the hot packages as well as the bottom of the PCB.  The RP4 still gets toasty in mine, but it works well enough if left in the open air (i.e. strapped to the back of the TV).  An RP5 is perfectly content in one of these.

I can’t get access to edit the MythTV wikis, so I’ll document my findings here:

• The advice on how to auto-start the front end using cron is…not ideal.  You can absolutely start it from the mythtv user account’s .profile.  You just need launch it only on a tty session and not for an ssh session.  I have mythtv setup to auto-login to tty1, so that is easy.  I have a few other configurable options in there, so I’ll share those files here (you can rip out what you don’t need).
  

  mythtv-autologin.tar.gz

• For the issue of the keyboard not working (important if you use a remote that masquerades as a keyboard like I do), it is just a permissions issue.  Add the mythtv user to the “input” group in /etc/groups and reboot.  Do not start MythTV from /etc/rc.local as the Wiki suggests; that will run the front end as root, which is a bad idea.
• The table showing how to setup the custom playback profile is out of date.  There is no MMAL decoder.  Use the “Standard” decoder instead.  The V4L2 decoder is still listed, but it is not very stable in my experience.  The other fields seem to work OK (4 CPUs, etc).  Use the “Medium quality” deinterlacer, not the low quality one as I have read in a few places.  I got horrible flicker with that one.
• Increase the read-ahead buffer in the advanced settings to quell some of the random stuttering you might see, depending on your network’s performance.  I set mine to 400ms, but you can go higher.
• There is no need to set the gpu_mem value in the firmware config.  The defaults for RP4 and RP5 are fine.  I am overclocking my RP4 as follows:
  

  arm_freq=2147
  over_voltage=6
  gpu_freq=750

With that feather in my cap, I decided to try a Raspberry Pi 5.  I’ve read a lot of conflicting opinions about its viability as a media player, but on paper it looks like a slam-dunk.  As with everything on Linux, the issues seem to stem more from the software support and not so much from the hardware.  The hardware is very capable.  All of the above applies to the RP5 just fine, it just needs a few workarounds at the moment.  These will probably not be needed in the future as support for RP5 matures.

• The front end will fail to start EGLFS.  This is because the RP5 has two devices for the two GPUs and EGL needs to use the second one for 2D OpenGL.  This can be addressed by passing the QPA layer a configuration file that specifies what device and display port to use.  Mine is included in the above archive.

Once it’s up and running, the RP5 works great as a front end.  Watching the same 1080p HEVC video that made the RP4 get out of breath caused the RP5 to hardly break a sweat.  I have not tried 4k yet, but it looks promising.  Things should only get better as support for hardware acceleration improves.