Home Media – Part 4 – OSMC/KODI/XBMC

This is part 4 of a series of write ups called Home Media.

Part 1 – The NAS build

Part 2 – The Setup

Part 3 – The Rip

Now that you have a whole infrastructure setup for streaming in your house, what do you do?

First thing is first, you will need some sort of hardware. Be it an old laptop, a Odroid-C2 box, an Android Box or a Raspberry Pi3. Then you will be creating two xml files called Sources.xml and/or AdvancedSettings.xml. These two files are responsible for media sources and database connections respectively. With Advancedsettings in the mix you can also add an SQL instance to your setup.

The benefit to the SQL database is that if you have multiple devices in your home, you can pause your content in one room and resume it in another. Your library info is stored in one place, the databse, and can be easily backed up and restored using software such as HeidiSQL. Library updates can be performed using headless installations of KODI and are picked up by all other devices on the network connected to the DB.

Easiest way to run a headless installation of KODI is to use the LinuxServer.io docker container which they have created and is available from here https://github.com/linuxserver/docker-kodi-headless. This works well if you have a server at home. If you are running a Pi or Odroid device with KODI on it this might not be necessary, since these are always on low power devices. Potentially you can send all update requests to these boxes.

For Laptop and Android Boxes go to their respective app stores and install KODI. On Linux you have to install KODI manually. Head over to Kodi.TV and they have all the packages you need over there. For further installation instructions head over to the KODI wiki.

In this example I will be working with v17.x or K, code named Krypton. For the Odroid-C2 and RaspberryPi I suggest heading over to LibreELEC and grabbing the installation source from there. The equivalent LibreELEC version of KODI version 17 is 8.x. For the Odroid and RPi you will need to image the storage device, SD card or eMMC storage. On Windows use the Rufus software. Alternatively LibreELEC has built their own installation tool to install the OS on a storage device. For further installation instruction for LE suing their tool go to their wiki site. An alternative to LibreELEC is OpenELEC, this has builds for devices that Libre does not support.

Note that when you boot in to KODI for the first time, specifically LibreELEC, you should enable SAMBA and SSH. SAMBA will be useful for copying the xml files to your KODI box later on.

Installation:

Once you have installed Rufus and plugged your SD/eMMC card to your computer start Rufus and locate the drive letter that is the storage device of your choosing.

In Rufus click the drop down list and select DD Image, then to the right of it click the image icon.

Rufus will prompt for a file with a Open selection window. Select the appropriate image and click Open.

It will warn you about erasing all the data on the storage device, accept the prompt and let Rufus run through it’s thing.

Once complete close Rufus and check that your file structure of the SD card look something like the above. The storage device is now ready to be plugged into your hardware and you can proceed to boot it.

Database:

Install the database of your choice. I use MariaDB, it’s a free open source SQL software. It was forked after MySQL was bought out by Oracle. I run this in a docker on my home server. However you like to proceed pick the installation of your choice.

The docker container is available on the Docker hub and can be found here: https://hub.docker.com/_/mariadb/

To run the docker with persistent storage run the following docker commands.

First you need to pull the installation.

docker pull mariadb:latest

An alternative to the latest tag you can use the versions available on the site, 5, 10… etc. Then you will need to run the docker using the docker run command. It will look something like the follwing.

docker run -d –restart=always –net=bridge –name mariadb -v /my/own/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=SomePassword -e MYSQL_USER=kodi -e MYSQL_PASSWORD=kodi -p 3306:3306 mariadb:latest

For Unraid 6 you can use a Docker MariaDB template available here:

https://github.com/Exist2Resist/docker-templates/tree/master/exist2resist

There are 3 key commands you need to execute on the database after you have installed it. You can find the database installation instructions for various OS versions on the KODI wiki.

Make sure after you setup a sa or root user on the database you write down the password. After this log into the database and run the following 3 commands.

  1. Type in: CREATE USER 'kodi' IDENTIFIED BY 'kodi'; and press return
  2. Type in: GRANT ALL ON *.* TO 'kodi'; and press return
  3. Type in: flush privileges; and press return

These commands create a user with the name kodi and password kodi. This will be used in your KODI installations via the advancedsettings.xml file to connect to the database.

sources.xml:

The sources file is used to connect KODI to your network shares and sources for your media and music. A sources file has the <sources></sources> tags at the beginning and end of the file and should look something like the following…

smb: stands for samba, your other option would be nfs which is the file sharing protocol in linux. Also if you notice the above shares are accessible to anyone on the local network. If you want to password protect these shares go ahead but you will need to change the <path>, using the example above to smb://username:password@Tower/Music/.

The sections (<music>), name (<name>) and path(<path>) are all mandatory in the example above. Every other field is optional.

Note that if you are using a database to store the media information you do not need the sources.xml file on all your instances of Kodi. You will only need both files on the instance which updates the library and database. All other instances only need to connect to the database. The database contains a files table which has an idPath column that stores the path to the files.

For further detail on the sources xml you can head over to the KODI wiki, http://kodi.wiki/view/Sources.xml

Note that with the database in the mix you should enable the option to wait for network before starting KODI. This is only available in OpenELEC and LibreELEC builds of KODI. I have not been able to find this in the vanilla KODI, but that should not matter as more than likely these installations will usually run on a box that requires manual KODI start anyways.

advancedsettings.xml:

The advanced settings file has the <advancedsettings></advancedsettings> tags at the beginning and end of the file and below is an example of what the advancedsettings.xml should look like. This file is very fickle and it has a lot of options it can take. Use the example below as a starting point.

<videodatabase> and <musicdatabase> point to an sql instance via the IP address username and password. Default port for sql is always 3306.

Also if you want to pause and resume your playback at different locations in your home, include the <importwatchedstate> and <importresumepoint> tags and set them to true under the <videolibrary> tag. Under the same tag <backgroundupdate> updates the library without any popups of notifications. <recentlyaddeditems> sets the amount of new items that will be visible under the TV Shows and Movies sections. Default I believe is 25, you can set this to whatever.

In version 17+ of KODI the cache tag is pretty important. If you are experiencing the odd buffering interruption while watching content from your file server set this option and have all content buffer.

In previous versions of KODI this option was set under the network tag. Sections 2.8.4 and 2.8.3 of the Advancedsettings.xml wiki, respectively.

Cache buffers the file in memory instead of the local storage. If you notice a lot of stutter on your streams, especially with version 17 if you add this sections the performance should greatly improve. Mind you if you have terrible internet and you are using external or http video sources there are no guarantees. If want to do this you will need to do some math first, use this bit calculator if you’d like, don’t trust google they mess the calculation and conversion up badly. But more on that later.

The cache section looks something like the following.

<cache>
<buffermode>1</buffermode>
<memorysize>477184000</memorysize>
<readfactor>10</readfactor>
</cache>

Buffer mode with value of 1 will cache any content streamed in KODI. Local or remote it doesn’t matter.

Memory size is where you will need to do some converting and calculating. So the max memory size depends on your system and this value can not exceed a third of your max free memory. So if your device is running while playing content with 300 MB of free memory your max memory size should be 100MB or 104857600 bytes. If you don’t adhere to the 1:3 ratio rule, there is a high probability that your box will crash.

Read factor is the speed at which the content gets buffered at or read into memory at. If a files average bit rate is 6MB/s, with a read factor of 10 the file will be read at 60MB/s into the cache buffer. Average bit rate multiplied by the read factor. Take your network bandwidth into consideration when calculating this. If not specified the default is 4.

For further details on the advancedsettings xml you can head over to the KODI wiki http://kodi.wiki/view/Advancedsettings.xml

File placement:

If you enabled SAMBA and SSH on your KODI device you can navigate to the Userdata share of the device and place both xml files there. Even though you don’t need both it is recommended that you do. The network name or IP will be required for you to navigate to the shared folder. You should have enabled SAMBA when you set up your KODI box. During said setup you gave the installation a name, if you kept it default navigating to \\LIBREELEC via file explorer should bring up the box’s shares.

Open up the Userdata folder and you should see some folders and 4 xml files.

Place both the XML files in here.

Alternatively you can SSH into your box using putty or similar software. Default user name is root and the password is libreelec.

Once in there you can use either vi or nano to create both the files and paste the contents. The location of where the file should be stored are as follows.

/storage/.kodi/userdata/

You can create the files manually by performing the following commands in SSH.

nano advancedsettings.xml

Then paste the contents of the file into the window and click ctrl + x, this will prompt you if you want to save the file, type in y and hit enter to confirm the file name.

Repeat the same for the sources file.

A very important step, you will need to set KODI to wait for the network when it boots if you are using a db connection. If you do not do this your library will not populate.

In your add-ons select the LibreELEC Configuration add on.

Then set the Wait for network… option and set it to 10 second. There has not been an instance where 10 seconds has not been enough for me.

Your KODI box should now be ready to go, reboot and enjoy.

Advertisements

HTPC? Go with Linux, try and avoid Windows based HTPCs.

A year and a half ago I switched my media server from Windows to Linux, this opened my eyes. A lot of people are afraid of Linux, people are afraid of what they don’t understand. I was a bit skeptical at first, but having made the switch I would never go back to a Windows based machine. Also I wanted to state that this article is not put here to start a flame war. I’m a heavy Windows user, these are just some observations of mine.

Main_logo_3DMy server serves up all the media from 7 Hard Drives totalling about 14 Terabytes of storage. I use XBMC to view all that media in my home. For those of you not familiar with XBMC, first I must ask, “Where have you been?”. XBMC is an award-winning free and open source (GPL) software media player and entertainment hub that can be installed on Linux, OSX, Windows, iOS, and Android, featuring a 10-foot user interface for use with televisions and remote controls. It allows users to play and view most videos, music, podcasts, and other digital media files from local and network storage media and the internet. That bit is straight from the horses mouth. It is probably one of the most popular media players for home theatre enthusiasts. If you have multiple televisions in your home you can point XBMC to an SQL database and sync content across rooms. If you are half way into a movie and you decide to stop it, you can continue where you left off in another room. It’s a very feature filled and rich media centre environment.

In my main living room where I have my home theatre setup, I’ve been running XBMC on top of a Windows machine for quite some time now. It has been very unstable, and more often than not if I brought the PC out of suspended mode XBMC would crash to desktop. My main reason for running this on top of Windows was that I also wanted to browse the web while in the living room. Finally I got annoyed at all the crashes and hangups with Windows. I could have ran in on top of Ubuntu, but instead I opted for an embedded XBMC solution. I had a choice either XBMCbuntu or OpenElec. I decided to go with OpenElec, to me it seemed like to more logical choice of the two. OpenElec is XBMC built from the ground up, on top of a Linux kernel. It is designed for light and small embedded media players. XBMCbuntu is an XBMC distro built on top of the Ubuntu kernel. I wanted the one with less bloatware. OpenElec stands for open embedded Linux entertainment center.

openelec_logoOnce I installed OpenElec and setup all my sources in XBMC I moved on to the testing phase. I wanted to test a couple movies. I ran a test on a movie i recently watched on my Windows based XBMC. Same hardware but different software. I played the movie and immediately I noticed the sound was a little louder, so i dropped the volume a couple notches, and continued watching. Meanwhile this is all playing through a 5.1 surround sound setup, and DTS is being decoded on the receiver. While listening I noticed something nice but not that surprising. The dynamic ranges in the movie were clearer and being reproduced a little better. The new XBMC Frodo (v12) Audio Engine (AE) and the linux audio stack was handling the audio a lot better than the Windows equivalent. Then I immediately recalled an article I read about 6 months ago where an audio engineer discusses the merits and accuracy of the Linux audio stack over the competition such as Windows. I wish I could link to the article, it was an interesting read. I also recalled that Windows audio stack or API as of the Vista version was no longer controlled by the hardware manufacturers but by the kernel of the OS. Some say that since Vista you don’t have true hardware DirectSound, instead you have software WASAPI which does mandatory resampling and frequency cutoff, and doesn’t allow any hardware effects such as CMSS-3D. This lead to some back lash from a lot of people back then, both hardware manufacturers and end users. In the end the audio experience is just as important to me as the video experience. I still buy Blue Rays because of the uncompressed video and audio quality, after all a movie should be an audio visual experience.

linux-wallpaperIn the end I’m glad I switched the HTPC to Linux. There is a noticeable performance increase on the audio side and just a general performance increase due to the smaller OS overhead from Linux and OpenElec. As for the web browsing part on my HTPC that I mentioned earlier, I found a third party Opera Browser plugin for OpenElec. Also as a side note, if you’re using a Raspberry Pi for XBMC, there is a huge performance increase with OpenElec over Raspbmc.

Here is a little clarification of the Windows audio subsystem taken from the XBMC Wiki:

Since Vista SP1, Windows has two primary audio interfaces, DirectSound and Wasapi (Windows Audio Session Application Programming Interface). The latter was a replacement for XP’s Kernal Streaming mode.

DirectSound acts as a program-friendly middle layer between the program and the audio driver, which in turn speaks to the audio hardware. With DS, Windows controls the sample rate, channel layout and other details of the audio stream. Every program using sound passes it’s data to DS, which then resamples as required so it can mix audio streams from any program together with system sounds.

The advantages are that programs don’t need resampling code or other complexities, and any program can play sounds at the same time as others, or the same time as system sounds, because they are all mixed to one format.

The disadvantages are that other programs can play at the same time, and that a program’s output gets mixed to whatever the system’s settings are. This means the program cannnot control the sampling rate, channel count, format, etc. Even more important for this thread is that you cannot pass through encoded formats, as DS will not decode them and it would otherwise bit-mangle them, and there is a loss of sonic quality involved in the mixing and resampling.

Partly to allow for cleaner, uncompromised or encoded audio, and for low-latency requirements like mixing and recording, MS re-vamped their Kernal Streaming mode from XP and came up with WASAPI.

WASAPI itself has two modes, shared and exclusive. Shared mode is in many ways similar to DS, so I won’t cover it here.

WASAPI exclusive mode bypasses the mixing/resampling layers of DS, and allows the application to negotiate directly with the audio driver what format it wishes to present the data in. This often involves some back-and-forth depending on the format specified and the device’s capabilities. Once a format is agreed upon, the application decides how it will present the data stream.

The normal manner is in push mode – a buffer is created which the audio device draws from, and the application pushes as much data in as it can to keep that buffer full. To do this it must constantly monitor the levels in the buffer, with short “sleeps” in between to allow other threads to run.

WASAPI, and most modern sound devices, also support a “pull” or “event-driven” mode. In this mode two buffers are used. The application gives the audio driver a call-back address or function, fills one buffer and starts playback, then goes off to do other processing. It can forget about the data stream for a while. Whenever one of the two buffers is empty, the audio driver “calls you back”, and gives you the address of the empty buffer. You fill this and go your way again. Between the two buffers there is a ping-pong action: one is in use and draining, the other is full and ready. As soon as the first is emptied the buffers are switched, and you are called upon to fill the empty one. So audio data is being “pulled” from the application by the audio driver, as opposed to “pushed” by the application.

WASAPI data is passed-through as-is, which is why you must negotiate capabilities with the audio driver (i.e. it must be compatible with the format you want to send it as there is no DS between to convert it), and why encoded formats like DTS can reach the receiver unchanged for decoding there.

Because WASAPI performs no mixing or resampling, it is best used in the exclusive mode, and as a result the application gets the exclusive rights to the audio buffers, to the exclusion of all other sounds or players. WASAPI shared mode does allow this, but that’s not a common mode and not what we want for an HTPC. I myself have a dislike of Window’s cutesy system sounds happening at 110db

Hope some of you found today’s primer of use. Please pick up a scorecard from the desk and drop it in the big round “collection box” on your way out

Cheers, Damian