Project PVR (part 2)

In my last article, I talked about my PVR hardware build.  This is now complete, so this blog post is going to talk about the software build.  The PVR software is entirely built on Debian so is entirely open-source apart from the binary firmware blob I needed to make my Hauppauge TV card work.

So here’s a list of the initial software I needed to make this work:

  • Stock install of Debian 9 (Stretch), which has Xorg and GNOME installed
  • Latest kernel from stretch-backports (this was 4.13.x at the time of writing)
  • tvheadend, installed from the official tvheadend Debian repository from their Web site
  • Kodi, installed from the official Debian package
  • The binary firmware blob for the Hauppauge WinTV-quadHD card (instructions for installing this can be found on the LinuxTV wiki

Needless to say, there were a few hiccups on the way:

Because the hardware I’m using is so new, I had to add an extra kernel parameter to /etc/default/grub which would enable “alpha” support for the Intel UHD 630 graphics on my CPU.  Supposedly this goes “production” in the 4.15 kernel, but until then you need to make sure you pass i915.alpha_support=1 in as a kernel boot parameter.

The next hiccup was Wayland.  I was hoping to use GNOME/Wayland plus xwayland to run Kodi on, as that is more modern (and over time I expect the X Window system will gradually disappear) but it would seem that OpenGL support doesn’t work properly in Wayland and that’s what Kodi uses to write to the screen.  This had the effect of dropping something like 10 frames per second on screen which made the screen look very jumpy.

The next hiccup was a bit puzzling and it took a lot of Googling to find it.  Kodi was working fine, but it was crashing at random whenever I watched a TV programme, live or recorded.  Eventually, I discovered why by looking through a lot of kodi crash log files and finding a suspicious message about “ERROR: JSONRPC Server: Failed to connect to sdpd”.  It turns out after searching for this error, that this is something to do with the Bluetooth userspace (perhaps using the same port).  So the fix was to uninstall the bluetooth package and all its dependencies and Kodi stopped crashing.

At this point, I’d largely got it working but there was one niggling problem remaining – the hardware acceleration was not working.  Although the CPU I have (Intel i3-8100) was perfectly able to cope with doing this in software, it was running all four cores at about 80% which seemed a bit high.  After doing a bit of investigation, it turns out that the VAAPI driver (video hardware decode acceleration API) for the Intel graphics chipsets in Stretch was not new enough to support the Coffee Lake graphics, so it was basically unable to use the hardware acceleration.  Running the vainfo command just returned an error.  At this point I had two choices – hope that either stretch-backports would include the 2.0.0 version of the driver that has support for Coffee Lake, or take the risk and upgrade to Buster (current Debian testing).  So, I decided (perhaps inadvisedly) to take the risk and do the upgrade to buster, hoping that nothing would break.  tvheadend still seems to be working, which is good,  and the output of vainfo now showed that there was a working, which is also good, as now I could get video hardware acceleration working.

Having started up Kodi again and making sure all the VAAPI options were enabled, I attempted to watch a recording.  The picture was good, no stuttering and pressing Ctrl+Alt+O on the keyboard to get the advanced stats on-screen display up showed that no frames were being dropped – also good.  CPU loading was down to around 20% per core plus or minus a few percent depending on what was being decoded – also much better than the 80% it was before.

But there was a problem.  The sound was choppy.  At first I thought that must be the VAAPI drivers at fault so I disabled them.  Still the audio was choppy.  Then I enabled the VDPAU support (which is a similar idea to VAAPI but is basically a subset of VAAPI) to see if that fixed it.  That didn’t either.  Then I tried to play a normal MP3 file- that worked fine, so at this point I could rule the sound card driver out.

Going back to the search engines again, it appears the problem is in Kodi.  The workaround is a little bit technical, but it’s all described in detail in Debian bug 881536 if you want to know the nitty-gritty details, but the one-line summary is that Kodi does something wrong with the ffmpeg API and it’s causing stuttering audio.  So I implemented the workaround in that bug, pending the proper fix being sorted out for buster, and thankfully the audio is back to normal again.

So now I have a working PVR, that records programmes, and plays them back correctly on the TV with hardware acceleration and so far I’m happy with the results.  The only major thing left to do is to get a “proper” remote control (as I prefer that over the Android-based one which is a bit fiddly to use), and that’s for the next part of this article.