Home Computers Installing Emby Inside OpenELEC

Installing Emby Inside OpenELEC

Installing Emby Inside OpenELEC

Emby Inside OpenELEC

This post and accompanying video is all about installing Emby inside OpenELEC so I should first explain why I want to do that and what the issue is that justifies its own post.

OpenELEC is an HTPC operating system that primarily runs the HTPC mediacenter Kodi off of a disk image in RAM. This results in super fast bootups and very simple setup, once installed.

Kodi, in turn, is a pretty fantastic HTPC front-end, but it does have two notable issues. The first is that there is no way to do remote streaming. That is, say you are on a trip and want to watch a movie from your collection that is served up by Kodi. That’s not possible. The second problem is the bigger one in my opinion. Kodi has a terrible interface for movie metadata management. This includes things like artwork and movie info and maybe trailers and all of the rest of the data bits associated with a movie file. The Kodi interface is stuck in the era from when it used to be XBMC and run on an XBox. This console-style interface is now incredibly antiquated and is honestly one of the worst interfaces I’ve ever seen for managing information like this. It’s so bad that it’s almost a deal-breaker for using Kodi!

Handily, there are products that fill in those gaps, namely Plex and Emby. Both are native remote streaming platforms; both have excellent modern movie metadata management; and both have addons that integrate their functionality with Kodi. Nice!

I tend to prefer Emby for Kodi integration partially because it is Open Source, partially because it is more flexible and more powerful when doing metadata management than Plex, but mostly because it completely takes over the Kodi database when the addon is installed. This is in comparison to Plex, which exists sort of as a side-piece to Kodi and the two maintain separate databases.

It is possible to run the Emby server on a separate computer and stream the content to Kodi — the addon does support that. Unfortunately, that setup defeats the primary advantage of a dedicated HTPC, as far as I’m concerned. Specifically, if you are okay with streaming or transcoding the movies over the network then you are likely better served with a Roku or FireTV box as the front-end running a Plex or Emby client. The power of a dedicated HTPC box is that everything runs locally, giving everything super fast reaction times and much tighter integration. Separating Kodi and Emby goes against that purpose.

The problem here is that OpenELEC does not easily permit 3rd party software to be installed after the initial installation. It runs off of a disk image in RAM and so anything running that’s not part of the image is typically wiped out on reboot. That means that for the Emby server to run locally, it will need to be included as part of the OpenELEC disk image.

That’s what this post is about — how to install Emby inside of the OpenELEC disk image to be part of the cohesive system.


Here’s the video for those who prefer talking pictures to words:

Step 0: Create a Linux Development PC

We’ll be compiling OpenELEC from source so we need a Linux PC to do the build on. I did mine the easy way and just installed VirtualBox and installed the lasted Ubuntu image onto it. If you have a dedicated Linux box then all the better since it will likely be much faster.

Step 1: Building the OpenELEC Disk Image

Start out by cloning my forked version of the OpenELEC source code:

$ git clone https://github.com/granworks/OpenELEC.tv.git

This will download a couple hundred megabytes of source bits and expand to use another hundred or so. Better have at least 300MB available for the source and then quite a bit more for the build.

Building the disk image is exactly the same as doing so for the stock image, since I made the Emby build a default option:

$ PROJECT=Generic ARCH=x86_64 make image 2>&1 | tee make.log

Technically only the part up to ‘image’ is needed — the latter part is there to log everything, which is useful for debugging if something goes wrong.

So… how long should this take? Well, it massively depends on your system. Probably a long time no matter what. On my VirtualBox instance running on a Mac Mini, it takes a staggering amount of time. It’s not “get a cup of coffee” amount of time but more like “set it going before going to bed and it’ll be mostly done by the time you wake up”. Yes, it takes at least eight hours to build on my system! Gak!

Install OpenELEC

When the build finishes, you’ll have a few files in the target directory. The ones that matter are those that end with img.gz, which is used for brand new installations and tar, which is used to update an existing OpenELEC installation. I have a previous video which covers the former case and the latter case is completely standard and described here

Install the Emby Addon

After rebooting OpenELEC, you’ll see the Emby server running, but it doesn’t communicate with Kodi at all since the Emby addon isn’t installed. I was unable to find a way to make that part of the disk image, so you’ll have to do that manually.

This page describes how to do that: Installing the Kodi Emby Add-on

What’s Missing

This setup is fully functional and is what I’m using on my HTPC as I write this. However, it is a bit of a hack. I was unable to coax the OpenELEC build process to successfully build the ‘mono’ package and so I resorted to pulling down a 64 bit pre-compiled package to use. This limits this image to only a 64 bit Intel chip and absolutely will not run on any other architecture such as the Raspberry Pi or a FireTV.

I was also unsuccessful in inserting the Kodo Emby repository into the disk image. I don’t know why that didn’t work since it seems pretty straightforward. Nevertheless, it’s not there, and so that addon needs to be installed manually.

It’s possible that if those two issues are fixed then my forked version could be merged back into the mainline, but until such day, this will need to remain a fork.


  1. Hi Kurt,
    Found your post after reading about Emby and wondering if i may be able to try it out on my openelec box.

    As a rank amateur to all things linux it has been a bit of a adventure ,
    I installed virtualbox and downloaded ubuntu 32bit as it seemed smaller
    For some reason it would not start after i installed it (twice), i thought to try it running the live version but quickly ran out of space.
    After some googling i gave up on that version and downloaded the 64bit version which has installed and run just fine – unfortunately my first attempt once again ran out of space – the 8GB default image size was too small.

    After making the virtual drive larger it ran for some time fine but has failed – the last lines it gave were

    CC src/basic/libbasic_la-dirent-util.lo
    CC src/basic/libbasic_la-xattr-util.lo
    Makefile:14070: recipe for target ‘src/basic/libbasic_la-xattr-util.lo’ failed
    make[3]: *** [src/basic/libbasic_la-xattr-util.lo] Error 1
    Makefile:18485: recipe for target ‘all-recursive’ failed
    make[2]: *** [all-recursive] Error 1
    Makefile:9196: recipe for target ‘all’ failed
    make[1]: *** [all] Error 2
    make[1]: Leaving directory ‘/home/node/OpenELEC.tv/build.OpenELEC-Generic.x86_64-8.0-devel/systemd-229/.x86_64-openelec-linux-gnu’
    Makefile:12: recipe for target ‘image’ failed
    make: *** [image] Error 2

    Any hints on what i can do to fix this?

    • As is, those error messages aren’t enough to debug the issue. BUT… I no longer recommend going that route. I uninstalled OpenELEC this weekend and switched over to LibreElec. It’s more actively maintained than OpenELEC and (critically) has built-in support for emby, without any need to compile anything or hack any code! It does require getting the Alpha version of LibreElec but so far it’s been pretty stable.

  2. Hello!
       First congratulations for the initiative!
      I would like to know it is possible to perform this image in a VM?
    It is possible to run on an Intel NUC?

    • No, I’ve not had any luck installing or running OpenELEC in a VM. It may be possible with VMWare Workstation with the right drivers, but I’ve never personally got it to work. Yes, it should work on an Intel NUC.

  3. Share the same thoughts on the limitations of kodi and its management. Well done with your initiatives! Wondering if you are only referring of installing emby as standalone or also the emby server? Just wondering as I am looking to find a easy way to install the emby server so my 6 kodi devices can access all data centrally. I have it now done using MySQL however it has limitations I am walking against. If your setup allows for multiple device movie management central access I am wondering if you could share the disk image? I am not good at making these disk images from scratch myself.

    • I ended up abandoning the hacked OpenELEC image in favor of a LibreElec alpha build, since that had Emby Server as an optional installable component. Keeping OpenELEC up to date was too much hassle compared to what LibreElec did. The Emby Server that is running on the *Elec box can create a central access point to any number of kodi devices, exactly like you’re thinking. I was doing that with OpenELEC + Kodi on a FireTV Stick. It worked great. The LibreELEC Alpha version doesn’t work as well with my Kodi instance on the FireTV, likely because the server and client are out of sync what with one being an alpha version and the other being a stable version. I’m confident that it’ll work again when the LibreELEC Alpha becomes stable.

  4. Why use openelec or libreelec at all?

    Surely a stock ubuntu/fedora/arch/insert-your-fave-here install with kodi and emby server installed on them would be a better choice

    Presumably the impetus for going with an appliance such as libreelec is that updates are easy and everything just works.
    The problem with this approach is that you have modified and had to build it yourself. You cant easily update etc.

    Later you will probably add something extra to it and it will be a complete PITA.

    I highly recommend something generic that’s designed to have extra packages installed.

    • You’re not wrong that a generic Linux distro would be a far more extensible choice. In fact, when OpenElec started giving me issues, my first inclination was to abandon the dedicated option and go the generic route. I then tried Kodibuntu, the latest Ubuntu LTS, and Ubuntu desktop… and I tried all three because each completely failed on me, in turn. Kodibuntu was simply far too out of date by default and it horribly broke when I updated the packages. The two Ubuntu variants are Ubuntu after all, but neither would recognize my bluetooth adapter and thus I was completely incapable of controlling Kodi via my Harmony Hub and remote. I spent a couple days playing around with blued and bluetooth profiles and all the rest of the standard messing around in /etc but to no avail — it simply wouldn’t allow me to use my remote. That was a fatal flaw to me.

      I then tried out LibreElec just to see if an alpha version would be workable and lo and behold, everything worked PERFECTLY out of the box. No messing with anything, no editing files, no jumping through hoops. It all just worked.

      And so that’s the key for me. More than anything else, I want a solution that does what I want it to do and does so with a minimum of fuss. Thus far, that solution is LibreElec in my HTPC.

  5. Cheers.

    I wonder if that now you have libreelec with the package. Whether it’s possible to say run docker straight from libreelec, with an emby image or some such. Not that I’m familiar with emby or libreelec. Thanks for the pointers.

    • In general, it shouldn’t be necessary to run emby inside of docker since LibreElec supports it natively. That said, the thought did come to mind recently when I discovered that emby server isn’t being updated to the latest due to the 3.1 version requiring a newer version of mono than the maintainers are readily okay with supporting right now. A solution to this might be to run emby server inside of a docker container, since then it wouldn’t conflict with anything else. I’ll wait a bit to see if this gets sorted out officially before devoting time into a potential docker solution, though.


Please enter your comment!
Please enter your name here