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.