How we got hardware acceleration of graphics to work in Ubuntu 18.04.2 with an Intel Core i7-9700K Coffee Lake processor

Intel Core I7.pngWe recently set up a new system using an Intel Core i7-9700K Coffee Lake processor, and discovered that the Intel® UHD Graphics 630 is not yet supported in Ubuntu, at least not in the 18.04 Long Term Support release. Therefore hardware acceleration of video did not work in Kodi or any other program. We first realized this when none of the VAAPI settings were shown in Kodi’s settings (they are normally found in Settings Player Settings Videos Processing).  Then we installed the vainfo program (using sudo apt install vainfo), and when we ran it we got this output:

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Obviously this is not what you want to see, so we knew we had a problem.  Much additional research led us to the conclusion that the Intel Core i7-9700K processor is so new that it’s not yet supported in Ubuntu 18.04.

After searching many pages and sites, the answer appeared in a post by user yasij in the Kodi forum, although it seems he thought you’d need to start with Ubuntu 18.10 or 19.04 (the latter should have support for this processor built in, but it’s not a Long Term Support release).

What we found was that support for this processor could be added to Ubuntu 18.04.2 – note the point version here, you need at least the 4.18 Linux kernel in that version for this to work. Check your kernel version using uname -a if you aren’t sure.

The method is rather simple, actually. First you run this command to add the necessary repository:

sudo add-apt-repository ppa:mamarley/updates

Then you need to edit the file etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list

nano etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list
(Or use your preferred text editor).

Look for the line:
deb http://ppa.launchpad.net/mamarley/updates/ubuntu bionic main

and change bionic to cosmic:

deb http://ppa.launchpad.net/mamarley/updates/ubuntu cosmic main

Exit nano (Ctrl-X) and save your changes. Then run:
sudo apt update
sudo apt install i965-va-driver va-driver-all
sudo apt install libasound2 libasound2-plugins

The last two packages were needed to get sound to work in Kodi. We use ALSA audio, so if you use PulseAudio you may not need those, or you may need to upgrade different packages. Additional dependencies may be installed when you install or upgrade these packages.

Then either delete etc/apt/sources.list.d/mamarley-ubuntu-updates-bionic.list or comment out that repository (add # to the start of the line, like this):
# deb http://ppa.launchpad.net/mamarley/updates/ubuntu cosmic main

Then run:
sudo apt update
again so that no additional packages from that repository are inadvertently added.

Reboot the system.

Now when you run vainfo the output should look something like this (with no errors):

libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileVP8Version0_3          :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSlice
      VAProfileVP9Profile2            :	VAEntrypointVLD

Note that if you run vainfo in a ssh session, you will probably see one error message right at the beginning of the output:

error: can't connect to X server!

This is to be expected in a ssh session, but that error should not appear if you run vainfo from a terminal window on the desktop.

That should be all you need to do — at least it was all we needed to do to get support for this processor into Ubuntu 18.04.2. We hope it works for you, too!  Note that you are mixing packages intended for different versions of Ubuntu, so there’s always a chance that doing this might cause some unintended breakage somewhere, but so far we haven’t encountered any problems.

Extending the remote control capabilities of LIRC

If you have installed the LIRC package on your computer so that it can receive signals from an infrared remote control (as we showed how to do in Ubuntu 18.04 in our previous article, Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi), you may have thought that you could only utilize it inside programs that have remote control support built-in, such as Kodi.  But did you know that you can also use your remote to execute any command that can be executed from a Linux command prompt, or even run a shell script to execute multiple commands?

In order to do that you need to do at least two things.  First, you need to run the irexec program (which is installed as part of the LIRC package), and second, you need to create a .lircrc file in your user directory.  In addition, you may wish to create shell scripts to do whatever you want.

An example may make things easier to understand.  Let’s take the case of starting or restarting Kodi from the desktop.  Let’s say you have just started up your system and it is sitting at the desktop waiting for you to start a program, and you want to start Kodi.  Sure, you could use your mouse to select Kodi and start it, but it’s more convenient to just be able to push a button on the remote to do it.  Or maybe you have been using Kodi and it has simply frozen up on you – wouldn’t it be nice to be able to push a button, kill the frozen instance of Kodi, and then restart Kodi?

Windows Media Center Edition compatible remote controlMost Windows Media Center Edition compatible remotes have four colored buttons, colored red, green, yellow, and blue, that don’t do anything inside Kodi by default. But, LIRC still recognizes them, and they are perfect for use in such an application.

The first thing you would need is a script to start Kodi.  Here’s a bash script that we use with Kodi 17.  Note that in Kodi 18 (at least in beta versions) some changes will need to be made, and these are noted in comment lines. Also note the comment about changing the value of yourusername in the “export USER=” line:

#!/bin/bash
# For Kodi V18 change AE_SINK=ALSA to KODI_AE_SINK=ALSA and
# all instances of kodi.bin to kodi-x11

# In the line below replace yourusername with your actual
# user name in Ubuntu (this will probably be the same as
# the name of your user directory)
export USER=yourusername

# Now try to kill existing Kodi if it is running
if ps -ef|grep -v grep|grep -i kodi.bin
then
ps aux|grep -i $USER|grep -v grep|grep -i kodi.bin|awk '{print $2}'|xargs kill
sleep 3
fi

# If it's still running, force kill it using kill -9
if ps -ef|grep -v grep|grep -i kodi.bin
then
ps aux|grep -i $USER|grep -v grep|grep -i kodi.bin|awk '{print $2}'|xargs kill -9
sleep 3
fi

# If it's STILL running it won't die, so exit
if ps -ef|grep -v grep|grep -i kodi.bin
then
exit
fi

# Delete old Kodi crashlogs (optional)
/bin/rm -f ~/kodi_crashlog-????????_??????.log

# Start Kodi using ALSA sound system
AE_SINK=ALSA nice -20 kodi --standalone &
exit

We saved this script as startkodi.sh and made it executable:

chmod +x startkodi.sh

Please note that we start Kodi with some specific options that you may or may not wish to use. To break them down:

AE_SINK=ALSA (this will change to KODI_AE_SINK=ALSA in Kodi 18): This usually forces Kodi to use the ALSA sound system rather than PulseAudio, which can give better performance if you are using passthrough audio in a multichannel system (5.1 or 7.1 audio). We say usually because on at least one system it was necessary to take more aggressive steps to kill PulseAudio before this would work (see the section headed “Disabling daemon autospawn” on this wiki page if you have this problem). You will know if it is working because you’ll need to reset your audio output under System Settings | System | Audio to use the ALSA output (and the PulseAudio options will disappear). If you are not using passthrough audio (using the “Allow passthrough” setting, and selecting a Passthrough audio device), then there is probably no reason to use this.

nice -20: This gives Kodi more CPU time than other processes that may be running at the same time, and therefore helps avoid jerkiness and dropped frames during playback.

kodi - -standalone: The recommended way to run Kodi from a shell script. (Please note there is a hidden character between the two – (hyphen) characters in this line, to force WordPress to display it correctly, so if you copy and paste this it won’t work if you don’t remove that hidden character.  Unfortunately, this is the case anyplace you see two adjacent hyphens in this article, except when they are within a code block.)

&: The ampersand at the end allows the script to exit immediately, without shutting down Kodi. It effectively makes Kodi a background task.

So that is the script we use to start Kodi, and of course we could run that from a terminal window (which you may want to do in order to check for errors), but that would not be very convenient. So, we use the .lircrc file (in the user’s home directory) to start the script when a button is pressed. We’ll use the green button in this example. Start by editing the file .lircrc (if it doesn’t already exist, this should create it):

nano ~/.lircrc

And just paste in these lines:

begin
 prog = irexec
 button = KEY_GREEN
 config = ~/startkodi.sh &
 repeat = 0
end

Then you can use Ctrl-X to exit nano (be sure to save the file).

The only other thing you need to do is make sure that the irexec program runs at startup. To do that, from the Ubuntu desktop bring up Startup Applications, and when it comes up click the Add button and enter these values:

Name: irexec
Command: irexec -d
Comment: Whatever you want, we used “Infrared Remote Control”

Add irexec to startup programs
Click the Add button to save it.

Then REBOOT THE SYSTEM.

Once the system has rebooted, you should be able to press the green button and it should run the startkodi.sh script and start Kodi. If it doesn’t, it’s probably because your remote is using different labels for the buttons, and we’ll cover how to determine that in a moment.  In case you are wondering, the -d option used with irexec is what makes it run as a background task.

Now maybe you’d like to be able to push the red button to stop Kodi in case it is hung, but without restarting it.  All you need to do is copy the startkodi.sh script to another script (call it stopkodi.sh), then edit that script to remove the line that starts Kodi, and then edit the .lircrc configuration to add another section:

begin
 prog = irexec
 button = KEY_RED
 config = ~/stopkodi.sh &
 repeat = 0
end

We can also run system commands directly from the .lircrc file. Let’s say we wanted to use the blue button to reboot the system, in case things really get messed up. We could add this to .lircrc:

begin
 prog = irexec
 button = KEY_BLUE
 config = sudo reboot
 repeat = 0
end

You would think this would work, but it won’t because when it tries to run sudo it will prompt for your password, and the script can’t deal with that. In order to avoid that, you’ll need to edit the /etc/sudoers file:

sudo nano /etc/sudoers

Move the cursor to the end of the file and on a new line add this:

yourusername ALL = NOPASSWD: /sbin/reboot

Replace yourusername with your your actual user name in Ubuntu. Use Ctrl-X to exit nano, and save the file. This allows running “sudo reboot” without needing to enter a password.

Remember that you will need to REBOOT THE SYSTEM before any changes take effect!

Now, if you are lucky these .lircrc configurations will work as shown. But if you have a different type of remote, you may need to use different buttons, or maybe the buttons aren’t returning the values that .lircrc is expecting to see. To determine that, from a Linux command prompt run this:

irw

Then while watching the terminal window or ssh session, press the buttons you are trying to use on the remote. As an example, here is what we see when we press the green button:

$ irw
000000037ff07ba3 00 KEY_GREEN mceusb
000000037ff07ba3 01 KEY_GREEN mceusb

Press Ctrl-C to exit irw. The thing you are looking for here is the button name, in this case it is KEY_GREEN as shown in the .lircrc section that starts Kodi above, but if your remote returns something other than that, that’s what you’ll need to use in the .lircrc file.  By the way, it is not unusual for a remote to send a button press two or three times in a row, just in case the infrared receiver misses it the first time.  This is not a cause for concern.

When you use irw as shown above, remember that lirc is still running, so don’t press any buttons that would take any action you don’t want to have happen, such as rebooting the system or launching Kodi or something else.

ADDING ADDITIONAL BUTTONS FROM THE SAME OR A DIFFERENT REMOTE

When you use irw, there’s a slight chance you might notice that your remote has one or more buttons that don’t generate any output at all, and maybe you’d like to make them recognized. Or, maybe you’d like to use a second remote (perhaps one that came with a device that you no longer use) to control some additional functions. These things are possible (usually) but the procedure is slightly complicated. One thing to keep in mind is that infrared receivers are only responsive to a certain part of the spectrum of infrared light, and some remotes may generate light pulses outside that range, in which case a particular remote may not work with a particular infrared receiver. But it’s worth a try.

Here’s the basic procedure for getting LIRC to recognize additional buttons:

Open the file /etc/lirc/lircd.conf in a text editor, or just do cat /etc/lirc/lircd.conf from a Linux command prompt, and note the contents – more than likely it will contain an “include” statement such as

include "/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb"

Open THAT file in a text editor and note how it is constructed. You will probably see definitions for one or more remotes, in sections between “begin remote” and “end remote” tags. In each such section you will see a list of codes, in sections between “begin codes” and “end codes”, and in such sections you will see two columns. The first is a list of names that have already been used for existing remote buttons, and that you therefore should not use when adding new buttons.

However, you cannot just go using any button names you like for your new buttons. You can only use the button names that are shown when you run this command from a Linux command prompt:

irrecord - -list-namespace

(Please note there is a hidden character between the two – (hyphen) characters in the above line, to force WordPress to display the line correctly, so if you copy and paste the above it won’t work if you don’t remove that hidden character.)

So to try to make this clear, when naming a new button you can only use names that appear in the list you get when you run irrecord - -list-namespace but you should NOT use names that appear in the /etc/lirc/lircd.conf file, or in any file that is mentioned in an include statement within that file, because you run the risk of specifying the same button name for two different buttons.

You may have to read that a couple of times for it to sink in, but it’s important. You will probably want to find a way to keep both lists visible during the next steps. You could open them in two different Text Editor windows, or two different terminal windows, or two different ssh sessions from another computer – it really doesn’t matter as long as you can refer to both lists, and know which is which.

Now you are ready to try to map new buttons. During this process, lircd cannot be running, so do this:

sudo killall lircd

Next, run this command:

sudo irrecord -d /dev/lirc0 ~/newremote.txt

The character at the end of lirc0 is a zero, not a letter O. You can use any filename you want rather than “newremote.txt”, just make sure it’s a filename you aren’t already using. When using irrecord, don’t try to add buttons from more than one remote in a single run, and if you make a mistake just Ctrl-C out, delete the “newremote.txt” file, and start over. Also, note the above line assumes that /dev/lirc0 is the correct path for LIRC’s connection to your infrared receiver, which is almost always the case.

The irrecord program will walk you through the entire procedure for adding new buttons — just follow the instructions it gives precisely. It will first have you perform some tasks so it can determine basic timing information about your remote.  If irrecord can’t seem to detect your remote, it may be that the remote isn’t compatible with your infrared receiver, or it may be that the batteries are dead in the remote! Don’t give up on a remote without at least trying new batteries.

After the preliminary tasks are completed, irrecord will ask you to enter the name of a button. This is when you will refer to the two lists — remember, you want to use a name that DOES appear in the irrecord - -list-namespace list, but that does NOT currently appear in /etc/lirc/lircd.conf or in any file referenced by an include statement therein (such as /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb in our example above).  Just to be clear, there is no requirement that the names you use in this procedure be in any way related to the names of the buttons on the remote, since you will be defining what the button press actually does in the .lircrc file.  It may be convenient to use a related name (if it’s not already used in another remote’s codes list) to help you remember which button is associated with which name, but if you can’t find an unused name that comes close to the name of the button on your remote,  it’s perfectly okay to pick any unused name from the irrecord - -list-namespace list and use that, though in that case you may want to make notes about which names are associated with which buttons.

After you enter the name, it will ask you to hold down the button on the remote. After a few moments it should ask you to enter the name for your next button – that is your confirmation that the button was accepted by your infrared receiver. You can keep on adding new buttons from the same remote, or exit by pressing only the Enter key when asked for the name of the next button.

Once you have exited irrecord, you must open the file it created (~/newremote.txt, or whatever name you used) in a text editor, and change the value on the name line (right below the line that reads “begin remote”) to something that is all lowercase letters with NO SPACES – underscore characters are okay, though.  So, something like

 name new_remote

would be fine.  The name must not duplicate the name in any of your existing remote definitions.  Also, we always remove all the commented-out lines produced by irrecord (lines that begin with a # character), since they are not needed.

After you have made those changes, copy the section starting with “begin remote” and ending with “end remote” to the clipboard, and then open the file containing your other remote definitions and carefully paste your new remote definitions to the end of that file (leave at least one blank line after the existing contents of the file before pasting).  By “the file containing your other remote definitions” we mean either /etc/lirc/lircd.conf or the file that is mentioned in an include statement within /etc/lirc/lircd.conf, such as /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb in our above example (we used the latter).  The basic idea is you want to put your new remote definitions and codes at the end of the same file that contains all the other remote definitions and codes. BE CAREFUL when doing this because if you somehow screw up this file, your remote may not work at all!  It probably isn’t the worst idea to make a backup of the file prior to making any changes.

If you don’t want to mess with your existing remote definitions file, you could probably add a new include line within /etc/lirc/lircd.conf and point that to a new file that you have created that contains your new remote definitions.  That is supposed to work, according to the LIRC documentation, but we haven’t actually tested doing it that way (please note that the LIRC documentation link takes you to the documentation for the latest version of LIRC, and therefore some parts may not be applicable if you are using an older LIRC version).

Note that if you were trying to add buttons from your main remote that LIRC has not previously recognized for some reason, you will probably want to add just those new codes directly to the existing codes list for that remote, rather than copying the entire new block of remote definitions.

You will probably want to save a backup of your new remote definitions someplace, so you don’t have to go through this process again the next time you upgrade the system!  This comment comes from experience — during our most recent Ubuntu upgrade, we backed up the entire home directory and some specific configurations from the /etc directory, but we totally forgot about the remote definitions that we had put into the /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb file, so we had to do redo this process.

Once you have added your new remote definitions and codes to the file containing your existing remote definitions and codes and saved it, you should REBOOT THE SYSTEM so that lircd will restart and read in the new codes.  After the system is rebooted, you can once again run irw and now when you press one of the buttons you added, it should show the name that you assigned to the button.  And if that works, you can then use that button name in the .lircrc file to launch shell scripts or system commands, or do just about anything you could do from a Linux command prompt.

Addendum:  Mind the Gap!  No, we haven’t been riding the London underground, but we have discovered that on some systems, but not others for some weird reason, if you add remote definitions that contain a “gap” value in the headers — which almost all added definitions will — it may cause LIRC to stop working altogether if for whatever reason irexec doesn’t like the gap value.  So if you have a gap value that is a bit on the high side (near or above 100000) you may need to reduce the gap value to get things working again.  For example in one case the gap value should have been 108382, but we wound up having to reduce it to 80000 on just one system for it to work, even though the higher value works fine on several other systems, and even though some of the other remote definitions had higher gap values.  The real issue is that if you get bitten by this, your remote won’t work at all until you change the gap value to something that irexec approves of — it will just silently fail to recognize your remote! This may even be a problem when you are copying remote definitions from one system to another — the gap value that works just fine on one system will cause the failure of your remote control to work at all on a different system.

How to fix Tvheadend being slow to start after a system reboot

If you run the Tvheadend PVR backend software, you may have noticed that after a system reboot it takes a long time to start back up, on the order of several minutes.  This problem seems to have become much worse recently, and we suspect but cannot prove that it has something to do with recent security updates that have slowed down the operation of some CPU’s.

The cause of this is most likely that you have thousands of very small files in your /home/hts/.hts/tvheadend/imagecache/meta directory.  It appears these get created on some systems when EPG data is updated, and never get removed unless the user removes them.  Each one contains a link to an image file on the internet, and the more of them that exist, the longer it takes for Tvheadend start.

Whether these files get saved in the first place is supposed to be controlled by the Configuration | General | Image Cache tab, which looks like this:

Tvheadend Image Cache tab
As you can see in the screenshot above, the Enabled: checkbox is not checked, yet we still had thousands of files.  The temporary solution is to click where it says Clean image (icon) cache, right above the Enabled: checkbox.  On our system this deleted the entire /home/hts/.hts/tvheadend/imagecache directory, including the “meta” subdirectory and the thousands of files therein.  The problem with that is that the next time Tvheadend gets new guide data, those directories may be re-created and start filling up with files again.  And another problem is that the cache contains channel icons and program thumbnails, which may or may not be used by your frontend player software.

As an example, Kodi may use the channel icons and program thumbnails in its guide, depending on how you have it set up.  But you also have the option to store channel icons on a system running Kodi in a specific directory, and then in Kodi go to System | Settings | PVR & Live TV | Menu/OSD and then in the Icons section change the “Folder with channel icons” value to point to the directory where the channel icons are stored. In that case, Kodi will not use any channel icons stored on the backend, so they don’t need to be saved by Tvheadend.

Screenshot of "Folder with channel icons" setting
As for program icons, those are a matter of personal preference, but we don’t feel they are desirable enough to tolerate system slowdowns.  We also suspect that when they are present, certain versions of Kodi running on slower or older systems may take noticeably longer to load data from the backend at startup, though we haven’t done any testing to confirm this.  This is an example of how a program icon might appear in Kodi – this is from the bottom of a program guide page:

Example of program icon on guide data page
Even on a large screen these icons are rendered so small as to be rather useless in our opinion, although the actual display size would depend on the skin used in Tvheadend and the guide display settings. But if you like them, just be aware that cleaning the image cache will make those go away.

Tvheadend probably should automatically clean stale files out of that cache, but it doesn’t. This is a known problem in Tvheadend, but is not targeted to be fixed until a 4.4 version release.

As for why these files get created in the first place, it’s typically because the software that creates the XML data file used by Tvheadend for EPG data includes links to icons.  For example, one popular program used to create schedule data XML files (Zap2xml) includes code sections such as these – the first creates links to channel icon files:

    if (defined($stations{$key}{logoURL})) {
      print $FH "\t\t<icon src=\"" . $stations{$key}{logoURL} . "\" />\n";
    }

And the second creates a link to the program icon for every program in the guide data!

      if (defined($programs{$p}{imageUrl})) {
        print $FH "\t\t<icon src=\"" . &enc($programs{$p}{imageUrl}) . "\" />\n";
      }

If these sections are commented out, the “<icon src=…” lines are not created in the XML file, and then when Tvheadend grabs the file it does not re-create the /home/hts/.hts/tvheadend/imagecache directory or add new files therein. If modifying the software that obtains the listings is not an option, one could run sed to remove any lines containing the “<icon src=” string from the XML file prior to running the grabber in Tvheadend:

sed -i '/<icon src=/d' /path/to/guide_data_file.xml

Either of the above methods will stop Tvheadend from ever seeing the links to the images, so it won’t create all those small files.  Of course, those methods only work if Tvheadend is getting its listings from a XML file.  But, maybe you want to see the channel icons or program thumbnails, or maybe you can’t figure out how Tvheadend is creating all those small files on your system.  In that case, you could simply delete only the files in the cache that are older than the number of days you store guide data for.  For example, this command would find and delete all files older than 15 days in the /home/hts/.hts/tvheadend/imagecache/meta file (this should all be on one single line):

/usr/bin/find /home/hts/.hts/tvheadend/imagecache/meta -mtime +15 -delete

You could run that as part of your script that gets new guide data, if you use such a script, or you could run that as a standalone cron job.  Note that “/usr/bin/find” was the correct path to the find command on our system.  You don’t need to specify the path to the find command if you are running it manually from the command line in Linux, but if you are putting it in a script or cron job you probably will need to include the path, and the easiest way to get the correct path is to run

which find

which will show you the correct path to the find command on your system.

But none of this should be necessary,  because unchecking the “Enabled:” checkbox in Tvheadend’s Image Cache tab should make Tvheadend ignore the image links when getting new guide data. Unfortunately, that does not seem to be the case.  Anyway, now you know the main reason why Tvheadend can be very slow to reload after a reboot.

Get Channel Icons Back for Recordings in Titan Skin on Kodi 17.6

If you ever used the Titan Skin under Kodi 15, you might have noticed that under Live TV Recordings there used to be a Channel Logo down in the lower right hand corner of the screen.  However, for some reason in Kodi 17 you see the Channel Logo in the Guide and Channels view, but not in the Recordings or Timers view.  This article will tell you how these two guys got them back.  I want to start off by saying that we did not create this fix, the credit goes to Kodi forum user “cartman.dos” – he was the one who figured this out.

This is what it looked like before the fix…

Untitled

Note that in the lower right corner of the screen you see the name of the channel as text, rather than the channel logo.

Now here is how you fix it. Note that all file paths shown below are valid in Ubuntu 18.04, but will probably be somewhat different on other operating systems, especially in MacOS or Windows. Start by running this command:

nano /home/YOURUSERNAME/.kodi/addons/skin.titan/1080i/IncludesVariables.xml

(In MacOS use “nano /Users/YOURUSERNAME/Library/Application Support/Kodi/addons/skin.titan/1080i/IncludesVariables.xml” instead.)

Once in nano hit Control-w and enter this in the search box:

 <variable name="channellogo">

You will then see this:

<variable name="channellogo">
    <value condition="!IsEmpty(Window(home).Property(SkinHelper.ListItem.ChannelLogo))">$INFO[Window(home).Property(SkinHelper.ListItem.ChannelLogo)]</value>
    <value condition="window.isactive(tvchannels) | window.isactive(tvguide)">$INFO[ListItem.Icon]</value>
</variable>

You need to add a line that looks like this:

    <value condition="String.IsEqual(ListItem.ChannelName,NASA Public Channel)">/home/YOURUSERNAME/TVCHANNELICONSFOLDER/NASA Public Channel.png</value>

Note that in the example above you need to make sure the two names in red are exactly the same and exactly the same name as your channel.  Also, you must replace YOURUSERNAME with your user name on your system, and TVCHANNELICONSFOLDER with the directory in which you store the channel icons.  This assumes that you have the icons stored in a directory off of your user directory – if not, replace /home/YOURUSERNAME/TVCHANNELICONSFOLDER/ with the correct path to your TV channel icons.

So the whole thing together would look like this…

<variable name="channellogo">
    <value condition="!IsEmpty(Window(home).Property(SkinHelper.ListItem.ChannelLogo))">$INFO[Window(home).Property(SkinHelper.ListItem.ChannelLogo)]</value>
    <value condition="window.isactive(tvchannels) | window.isactive(tvguide)">$INFO[ListItem.Icon]</value>
    <value condition="String.IsEqual(ListItem.ChannelName,NASA Public Channel)">/home/YOURUSERNAME/TVCHANNELICONSFOLDER/NASA Public Channel.png</value>
</variable>

In the same way, you just add in as many channels as you want logos for.

Here is what it looks like after you make the changes…

Untitled 2

Note the channel logo is now present in the lower right corner of the screen, rather than the name of the channel as text.

Hope this helps others wanting their Channel Logos back.

How to install Kodi media player to Ubuntu 18.04 (Bionic Beaver) Desktop

Kodi Startup Logo

We recently wanted to install the Kodi media player software to a system running Ubuntu 18.04 desktop.  Here is the procedure we followed.  Not all of these steps are necessary, and we will tell you which ones are optional.

1. Optional – Install openssh-server and/or vino

If you install openssh-server you will be able to ssh into your system from another computer on your network (which gets you to a Linux command prompt, similar to running the Terminal program), and this will make things easier if you wish to do any of the installation steps from a different system. Similarly, vino allows you to use any VNC client to remotely access the desktop on your system. If you plan to do all the configuration directly on the Ubuntu desktop system then you do not need either of these. To install openssh-server do this:

sudo apt install openssh-server

If you want to install vino there is a two step process, and the second step must be done directly from the system running Ubuntu 18.04 desktop – you cannot do it through a ssh connection. The first step is probably only necessary if you did a minimal install of Ubuntu, but you can try it anyway just to make sure it’s installed:

sudo apt install vino

Then, to make it possible to connect from a remote client (particularly one running on a non-Linux system), open a Terminal window on the Ubuntu system and enter this:

gsettings set org.gnome.Vino require-encryption false

Note that “Vino” is capitalized in the above line – it won’t work if the V is lowercase. After doing this you should be able to set up Screen Sharing from the System Settings menu. If you aren’t familiar with that process, see this tutorial.

2. Optional – Set a static IP address

If this is going to be primarily a media center or home theater computer, you may want to be able to always find it at the same IP address on the network. If that is the case, consider giving it a static IP address. This is done by clicking on the Network icon in the upper right of the desktop and changing the settings associated with the correct network interface. If you are not familiar with this process, see this page but scroll down to the section headed “Ubuntu Desktop” – it’s where you will find the first screenshot on the page.

3. Optional – If you are using wired Ethernet, disable the Wi-Fi interface

While you are in the network settings, it’s a good idea to disable the Wi-Fi interface if you don’t plan on using it. If you try to connect to any type of streaming content, such as YouTube, you will generally have a far more reliable connection if only a wired connection is available.

4. Install Kodi

Now that we have the preliminaries out of the way, it is time to install Kodi. The process is quite simple and can be found at their page, HOW-TO:Install Kodi for Linux but it is so easy we can tell you how to do it here. Just open a terminal window or ssh session and enter the following. The first line is probably not needed, because the “software-properties-common” package appears to be already installed in Ubuntu, but just to be on the safe side you may want to run it anyway:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:team-xbmc/ppa
sudo apt-get update
sudo apt-get install kodi

5. Optional – If you run a backend system such as Tvheadend in order to use the Live TV and PVR features of Kodi, install the appropriate PVR client add-on. Instructions can be found on this page. If you don’t know what a backend system is, you can skip this step for now, but at some point you may want to read up on Tvheadend and how it is used with Kodi.

At this point you should find the icon for Kodi among your applications, and you should be able to launch it and control it with your keyboard. You will want to go through the settings and set it up the way you like. Also, if you installed a PVR add-on, you will need to configure and enable it. And, you may want to install some additional Kodi add-ons, which can be found on this page.

PLEASE NOTE: The add-ons at the above link are free and legal addons from the official Kodi site. We STRONGLY recommend that you DO NOT install add-ons from any other site. If an add-on has not been accepted into the official Kodi repository, there is a good chance it is illegal in many parts of the world, and that it could irreparably damage your Kodi installation or even your system. In the worst case, it may contain a virus or a “trojan horse” program designed to steal your personal information and passwords. There are a few benign Kodi add-ons from third-party sites, mostly ones still in the development stage where the author hopes to get them accepted into the official Kodi repository, but unless you are knowledgeable enough to figure out which add-ons can damage your system and which cannot, we’d recommending avoiding add-ons from third-party sites like the plague. If you have ever read any negative articles about “illegal Kodi boxes”, these are boxes that have been pre-loaded with illegal and often poor quality add-on software, that are usually sold at a highly inflated price and that contain apps that will stop working in a matter of days or weeks, at which point you find out the seller has left town never to be seen again. Kodi itself is a free and legal program, as are the add-ons that are found at the official Kodi site.

6. Optional – Make a Windows MCE compatible remote work correctly in Kodi

If you have a Windows Media Center Edition compatible remote attached to your system and you have its infrared receiver connected, you will probably find that some buttons (such as ENTER or OK) do not work in Kodi. In past versions of Ubuntu the simple solution was to install a program called LIRC, but the version of LIRC in the Ubuntu 18.04 repository is buggy and doesn’t work correctly. The fix for that is found in our previous article, Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi.

7. Optional, for users with Intel graphics only – Create a Xorg configuration for smoother video playback (this section added October 2, 2018):

We’ve been watching a thread on the Kodi forum called “v18 – Is there a guide to perfect playback in Ubuntu 18.04 Deskop using VAAPI graphics?” that you may want to read.  But the gist of it seems to be that starting in Ubuntu 18.04, by default the video driver used is not the best driver for use with Kodi.  As user “yasij” wrote:

…Xorg has been the default in every [Ubuntu] release except 17.10, which has Wayland.

In 16.10, Ubuntu switched to using the modesetting driver with glamor on Intel gen4 graphics and newer instead of xserver-xorg-video-intel.

But Kodi works best with the xserver-xorg-video-intel driver – Team-Kodi Developer “FernetMenta” wrote:

You really should create a xorg.conf that forces intel driver. Otherwise it would use modeset driver that causes stuttering on most hardware.

And in an earlier message he wrote:

Make sure you have TripleBuffer disabled in xorg.conf. This is enabled by default

If you don’t already have a Xorg configuration file, the easiest way to do this seems to be this:

sudo mkdir -p /etc/X11/xorg.conf.d
sudo cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11/xorg.conf.d/10-intel.conf

(Note there are only two lines above; if the second one wraps on your screen it’s still all one line.)

Then edit the 10-intel.conf file – this shows using nano, but feel free to use another text editor if you prefer:

sudo nano /etc/X11/xorg.conf.d/10-intel.conf

Right after the existing line Driver "intel" add this new line:

Option "TripleBuffer" "false"

Check to make sure you have not made any mistakes. At this point it should look something like this (the commented out line may or may not be present):

Section "Device"
        Identifier "Intel"
        Driver "intel"
        Option "TripleBuffer" "false"
#       Option "AccelMethod" "uxa"
EndSection

Press Ctrl-X to exit, and save the file.

It might be a good idea at this point to make sure you can ssh into your system, just in case your hardware is different and this change prevents the desktop from starting up.

Reboot the system, and after it comes back up you should hopefully find that video playback in Kodi is steadier.  If for any reason this change has caused problems, simply remove the new file:

sudo rm /etc/X11/xorg.conf.d/10-intel.conf

And reboot. Note that if your desktop won’t start up, you’ll need to do this in a ssh session or from a command prompt. If the desktop won’t start, it may mean you have incompatible hardware (are you certain you have Intel graphics?).

Also, if you are an AMD user, you may have to perform some additional steps – see at least the second post in this thread. At the very minimum, it appears you may need to use Kodi version 18 (Leia) and do this (again, this is for AMD users only):

AMD users that want to use kodi v18 with vaapi (Take care: v17 won’t work), you need to install mesa 18.0.1 or later. You can do this via Paulo’s ppa:

sudo add-apt-repository ppa:paulo-miguel-dias/pkppa
sudo apt-get update
sudo apt-get dist-upgrade

We are not AMD users, so you are kind of on your own with the instructions in that thread – good luck!

8. Optional – Install Gnome Tweaks

One other thing you may wish to do is install Gnome Tweaks if you have not done so already. Just go to the Ubuntu Software Center and search for “Gnome Tweaks” and install it, and you will have more control over how your desktop looks and operates. For example, if you want to remove the trashcan icon from the desktop, see this article. But a better use might be to turn off animations, which could slow down an underpowered system and which some users find annoying. You can turn off animations in the Gnome Tweaks Appearance tab.

Make LIRC work in Ubuntu 18.04, so that you can use your infrared remote in Kodi

remote.png

If you are a Kodi user and have recently tried to upgrade your system to Ubuntu 18.04, and then tried to install and use LIRC to make your infrared remote control work the way it should, you may have discovered that it doesn’t work. For one thing, you don’t get the configuration menu during the install process, so you can’t select your make and model of remote. Even the old standby of using sudo dpkg-reconfigure lirc to bring up the configuration menu doesn’t work anymore.

Chances are you searched the web for an answer, but perhaps you never found anything that would make your remote work as smoothly as it used to in past versions of Ubuntu. Even if you got the remote to work in Kodi, you probably got double button presses or a lack of response to button presses on some buttons at random times, and maybe certain buttons would not work at all. We have heard of Kodi users giving up and going back to Ubuntu 16.04 because of this issue!

It turns out that the issue may not be with Ubuntu OR Kodi.  It appears the problem is that the Ubuntu 18.04 repositories contain a newer version of LIRC, that just doesn’t work properly.  We found that going back to an old version, specifically LIRC 0.9.0, is the answer – install that, and you do get a version of LIRC that works in Ubuntu 18.04 and that makes your remote work smooth as silk in Kodi.  Well, at least it did for ours, which is a standard Windows MCE compatible remote similar to the one pictured above.

So how do you do that?  Well, as the title of this blog implies, we are two “sort of” tech guys, and one thing we are not is Linux experts.  So, we took an approach that is relatively easy and that works, even if it may not be the “most correct” way to do it.  Here’s the procedure we used:

First, remove any existing installs of ir-keytable and/or lirc – from Linux command line do:

sudo apt purge ir-keytable lirc

Also, if you have added any other software in an attempt to get the remote to work, you probably should remove that as well.

Next, we’re going to temporarily edit /etc/apt/sources.list – we will use nano, but feel free to use vi or vim if that’s your thing:

sudo nano /etc/apt/sources.list

Add this line at the bottom of the /etc/apt/sources.list file:

deb http://ca.archive.ubuntu.com/ubuntu/ xenial universe

Use Ctrl-X to exit nano; be sure to save the file (unless you made a mistake, then just exit without saving and start over).

Then, from the Linux command line:

sudo apt update
sudo apt install lirc/xenial

You should see it install lirc and a few dependencies.  Somewhere in the process you should see “Setting up lirc (0.9.0-0ubuntu6) …” and also you should get the configuration screen, from which you can pick the type of infrared remote you use (such as “Windows Media Center Transceivers/Remotes (all)”, which is down near the bottom of the list).

lirc configuration screenClick on the image to enlarge

After that is finished, do this so Ubuntu won’t try to upgrade lirc to the newer bad version:

sudo apt-mark hold lirc

Now that lirc is installed, you need to go back and remove the line you just added to /etc/apt/sources.list:

sudo nano /etc/apt/sources.list

Scroll down to the bottom of the file and put the cursor at the start of this line and press Ctrl-K to delete it:

deb http://ca.archive.ubuntu.com/ubuntu/ xenial universe

As before use Ctrl-X to exit nano, and be sure to save the file.

Now from the command line you should immediately do this so that your system doesn’t inadvertently try to get any other packages from the xenial universe repository:

sudo apt update

And that’s it!  What we have done here is to temporarily enable the Ubuntu 16.04 (xenial) universe repository, where a copy of lirc 0.9.0 is available, and then we installed it using the apt command.

We do realize that there may be alternative way to do this, such as downloading the lirc package from the xenial repository (the amd64 version is here) and then installing it using dpkg, but we’d be a little concerned that doing it that way either might not bring in the necessary dependencies, or might not show the configuration menu.  But, feel free to try doing it that way if you’re much more conversant with Linux than we are.

We hope this helps others who have struggled to get their infrared remote working with Kodi in Ubuntu 18.04!

If you liked this article, you may also want to read our followup article: Extending the remote control capabilities of LIRC.