How to build a versatile budget multimedia center
Teachers! Did you use this instructable in your classroom?
Add a Teacher Note to share how you incorporated it into your lesson.
Step 1: 1. Introduction
is a form of activity that holds the attention and interest of an audience, or gives pleasure and delight. It can be an idea or a task, but is more likely to be one of the activities or events that have developed over thousands of years specifically for the purpose of keeping an audience's attention.
Although people's attention is held by different things, because individuals have different preferences in entertainment, most forms are recognizable and familiar. Storytelling, music, drama, dance, and different kinds of performance exist in all cultures, were supported in royal courts, developed into sophisticated forms and over time became available to all citizens. The process has been accelerated in modern times by an entertainment industry which records and sells entertainment products. Entertainment evolves and can be adapted to suit any scale, ranging from an individual who chooses a private entertainment, like watching television (movies, tv series), listening to music. This became a daily activity for almost everybody.
Since computers appeared in each modern household, this started to be used also for entertainment purposes. Listening to online (or downloaded) music, watching streamed videos or downloaded movies (although illegal in some cases) is nowadays a common habit. Modern computers tend to have lower power consumption, and they come also in smaller form factors. These are ideal candidates for building HTPCs (Home Theater PCs). ARM based processors also became powerful enough to easily decode 1080p (HD) content, therefore also these became quite common in HTPC setups. More important would be the software aspect, as even the most powerful setup can be cumbersome to be used if the GUI (Graphical User Interface) was not designed to be used with a remote control/television. As it will be treated in the next chapters, luckily there some powerful and open source solutions available.
Step 2: 2. Hardware Setup
choosing the right hardware setup, we should decide what software will be run on it. Currently there are 2 available choices: Plex media center or Emby and Kodi. All of these can present media content in a beautiful way, but there is a big difference in the approach: Plex and Emby are mainly stream based (they provide content which can be streamed towards clients, like a smart TV, media player, Chromecast) while Kodi is a standalone media center, indented to be run on a device which is directly connected to a TV. As we want to build a media center, the best choice is Kodi.
Kodi (formerly known as XBMC) is media player software that can play most video and music file types and other digital media both saved locally and found on the Internet. It's a one-stop-shop for all your entertainment needs once you get it set up right. It takes a little tinkering to get it running, but once you do it'll be smarter than any smart TV on the market.
The software is highly customizable to suit your particular media center needs, and it works with Windows, Linux, OS X, Android, iOS, Raspberry Pi and more, making it flexible no matter what computer you're basing your media center on.
if a HTPC is more powerful than an embedded device, the cost of a raspberry pi is less than 50$ and luckily it can run Kodi without a glitch. Also software support is the best among these types of boards, therefore it will be an ideal candidate.
The specifications or model 2 B are the following:
· A 900MHz quad-core ARM Cortex-A7 CPU
· 1GB RAM
Like the (Pi 1) Model B+, it also has:
· 4 USB ports
· 40 GPIO pins
· Full HDMI port
· Ethernet port
· Combined 3.5mm audio jack and composite video
· Camera interface (CSI)
· Display interface (DSI)
· Micro SD card slot
· VideoCore IV 3D graphics core.
The recently released Raspberry 3 comes with in even higher clock rate and has already wifi and bluetooth support built in. This reduces the overall cost, as you won't need a bluetooth or wifi dongle any more. However, still ethernet connection is preferred, in case you really want to stream 1080p video content.
The videocore is capable of decoding in HW content encoded in MPEG, H.264 formats, and therefore it will handle almost all media available nowadays. The trend is going towards 4k and H.265, but the transition to it will be slow, if we look back at the transition from SD to HD content, therefore this setup will be future-proof for the next few years.
Kodi media center has a great support for addons, and can act as a live tv client also. If we connect an USB tv tuner to it, the media center can be also transformed into a set top box, capable of receiving tv conent from satellite, cable or terrestrial sources.
As no media center looks stylish enough without a small display, we will fit our media center with an HD44780 compatible 16x2 segment alphanumerical display. These are quite common, can be LCD, VFD (vacuum fluoride displays), can be driven via 4lines, 8lines, but there are also variants the use I2C or have an USB converter on them. The cheapest one are those without additional converters, and this will be used.
For remote controlling there are quite a lot of possibilities. If the raspberry PI is connected to a CEC compatible TV, then the TV’s remote can also command the media center. If the TV is not capable of this, then a simple IR receiver, like the TSOP38238 and the proper sw package will do the job. Also, there is a possibility to remote control Kodi via a mobile phone app. There are more choices, best of them is Yatse, which can be downloaded from Google play store or Apple Store.
In the end, the material list is the following:
1) Raspberry 2 Single board computer
2) USB DVB-S2 tuner, supported by the linux kernel. Now this is the tricky part, you have to choose it wisely, as not all tuners are supported, some have problems, while others can be made functional only after some workarounds.
Nevertheless, there are a few tuners that have good community and the supplier explicitly supports linux. I can recommend one of the 2 above, as they are relatively easy to purchase:
-> Dvbsky tv tuners:
For DVB-S2 satellite reception: http://dvbsky.net/Products_S960.html
For DVB-C, T cable or terrestrial reception: http://dvbsky.net/Products_T680C.html
->Sundtek tv tuners:
The Dvbsky costs around 59 Euro, while the sundtek 89.
As the first one is cheaper, this will be a good candidate.
3) TSOP38238 infrared receiver
4) HD44780 compatible LCD or VFD. As the VFD looks more ‘professional’, the Artronic VFD- AC-1602H-BG-5V was chosen:
5) Fitting an USB hub will make it easier to connect additional USB devices to it, for example, Wifi dongle, mouse/keyboard dongle, Bluetooth dongle, etc.
The wiring of the TV tuner is simple, as it connects to the Raspberry Pi via USB cable. The wiring of the LCD and IR receiver will be discussed in the chapters describing the actual installation, as the wiring and the software configuration depend on each other.
6) The power distribution board is made on a test PCB, but meanwhile I've created one in EasyEDA. You can order it directly from the website:
Step 3: 3. Mechanical Setup
To make it look nice, all of the above components will
be installed into the housing of an old set-top box. The choice is merely based on preference, but it should be large enough to house all of the components above: the raspberry Pi2, LCD, Tv Tuner and USB hub.
Step 4: 4. Software Setup
steps required to setup a working media center with live tv capabilities are briefly the ones below:
1) - Install linux image with Kodi media center
2) - Install necessary firmware files (if needed) to make it recognize the dvb tuner - already working out of the box for most of the times
3) - Install and configure tvheadend server - responsible for the reception of tv channels
4) - Install and configure tvheadend client addon for Kodi
5) [Optional] Install oscam to watch encrypted channels - if you have a valid subscription card
Step 5: 1) Install Linux Image With Kodi Media Center
are 2 distributions actively developed, one is Openelec and the second one is OSMC. Both offer great support with good community, but there is a difference between the 2 of them:
Openelec is just a slip-streamed Linux distribution with the kodi addon, so there is no software repository, therefore, you will NOT be able to build your custom version of these softwares, you can use only the precompiled versions provided by the Openelec Unofficial addon. For most of the cases, this is ok, as you can get the precompiled add-on directly from the GUI, similar to how you download addons for enigma2 based boxes. But these are not always the most up-to-date versions, so in case you need to build from a GIT repo, you won't be able to do so with Openelec.
OSMC: This distribution, formerly named Rasbmc is a full debian distro, this means there is an APT repository that contains mostly the Raspbian packages, but it has also some own repos, from where you can update OSMC specific packages. This has the advantage that in case you need to install some additional packages, or you need to install a build chain to be able to build tvheadend, oscam , lcdproc or anything else, you will be able to do so.
This does not mean that it's more difficult to use than Openelec. You have a GUI from where you can install pre-built packages for tvheadend, transmission, etc., so in case you are a beginner, there's no big difference between the 2 distros. But once you start to understand how things work, and you have to install additional packages, the full debian distro will come in handy.
The installation is quite straightforward for both distros.
For Openelec, you download the RPI2 disk image (NOT the update file), and write it to an SDCARD with any image writer program.The image you can download it from here:
Install instructions are provided here:
For OSMC, the installation is similar, but you don't have to use Imagewriter, nor you have to download manually the image, as they have a nice GUI interface that downloads the necessary image.
In both cases, once you finish writing the SD card, take out the sd-card from the computer, place it inside the RPi2, and start it (make sure you are connected to the internet via Ethernet cable).
Step 6: 2) Install Necessary Firmware Files (if Needed) to Make It Recognize the Dvb Tuner - Already Working Out of the Box for Most of the Times
we proceed, we need to understand how the TV support is implemented in Linux.
We won't go into deep details regarding this, as most of the times you won't need it, but understanding the principles of something will always help you in case you encounter problems.
In Linux, if a device is supported by the linux kernel, it will work out of the box, once you plug it in. If it doesn't, then it means that the support for the device is not compiled in the kernel, but might be available separately, as a module. This is how it works nowadays, as building support in the kernel for every device would make the kernel image too big. So it's preferred to keep them separately in modules and load them only if necessary. This can be done automatically by running the necessary script once the device is plugged in, or manually. In this latter case, you need to load the necessary kernel module (this is similar to a 'driver' in windows) to make it work. You need to follow the description, but usually adding it to /etc/modules.conf will do the trick.
If there is no kernel module, then most probably you are out of luck, as your device won't be supported.
If you have chosen the Dvbsky tuner, then the tuner will be recognized out-of-the box.
In order to check it if the device is recognized, open up a ssh console session (openelec has user: openelec, pass: openelec by default, osmc has user: osmc, pass: osmc) , and issue a lsusb command (see first picture for output)
case you don't have the lusb command, you can install itt from repository on osmc via the command:
sudo apt-get install usbutils
We should get an output similar with picture nr 2.
the output does not show the tuner as found, it will work.
If it displays some error that a firmware file is not found, we need to copy the firmware file(s) for your tuner and copy/extract it to /lib/firmware/ folder.
To understand why this is necessary, a brief explanation is needed:
Usually every modern equipment has a processor that needs to run certain firmware in order to work. This is stored usually inside the Flash memory of the processor, in some cases externally in the attached NAND memory. But in case of TV tuners, most manufacturers chose not to store it at all in the equipment, but instead the operating system will load it every time the product is inserted/started up. This not only spares the NAND memory, but makes it easier and safer to maintain and update the firmware required to run the hardware.
In our case, once the Linux recognizes the device and loads it's associated 'driver', it will try to load the respective firmware from the /lib/firmware folder.
Some distros already place these firmware files in that folder, in this case the 'driver' will find it and load it inside the tuner's RAM memory. Some distros don't include it, as it's usually better to use the most up-to-date firmware files that are provided by the tuner's manufacturer.
In case of the Dvbsky tuner, the most recent firmware files can be downloaded from the following link:
For the Sundtek tuner, the situation is different. The tuner has also an userspace driver and you will have to download the firmware separately in order to make it work. It should be available from the repository under 'Program addons' or 'Services'.
Note: If you are using an Odroid C2 insted of the Raspberry Pi (see the HEVC and 4K section) then you will need to stick with the community build made by Raybuntu or the official Libreelec build. Note that the Dvbsky tuner is only supported on the community builds (media_builds) and not the official ones.
Step 7: 3) Install and Configure Tvheadend Server - Responsible for the Reception of TV Channels
this point, we must have a working TV tuner. In case the dmesg command reports error, then we need to revise the support for the tuner.
The Client - Server architecture of tvheadend is very clever, as it separates the reception part from the viewer part. This means, that we can have the TV server on one device, and watch the channels on a completely different device. The only condition is to have a good network speed between the 2 devices. Good means 4-5 Mbps for SD channels and 20-30 Mbps for HD channels.
We have 2 options: install the pre-built binary, available in Osmc's or Openelec's repository, or build our own from sources.
The first one has the advantage that requires less effort and it's easier to install. But we won't get the latest version. As the tvheadend has a good community, new versions are added very often.
The recommendation would be to start with the version bundled with Osmc or Openelec and only build it from the sources in case we encounter issues that prevent it from working properly.
Installing the tvheadend server on OSMC:
From the App store (Programs -> My osmc) or from Openelec’s unofficial add-on repository we can download and install it.
In the end, after a successful installation of tvheadend, you shall be able to access the web interface of tvheadend on the following address:
The default username and password for OSMC is for both osmc, for Openelec is openelec.
Once we are connected to the web interface, we can configure everything from here. And only from here. Usually, the clients are very simple, thin clients and they offer only channel viewing (or grouping) and EPG.
Briefly, the following steps must be done:
1) Configure the available adapters
2) Define the Networks
3) Add Muxes (if not already available) and scan them to get the Services
4) Map the services to channels - more on this in the following chapters
3.1. Configure the available adapters
The following steps must be done
from the web interface of the tvheadend server.
Going to the Configuration -> DVB Inputs -> TV Adapters tab, the TV adapter must be visible, in case of a DVB-S tuner, it shall read:
Montage Technology M88DS3103 : DVB-S #0 for the DVBSky tuner or:
Sundtek DVB-S/S2 (VI) #1 : DVB-S #0 for the Sundtek tuner.
In case of a DVB-C or a different tuner, the name of the tuner (or the chipset being used) shall appear.
If the tuner adapter can't be seen in this list, then the TV tuner is not correctly recognized. If you've bought the DVBSky tuner, then most probably you are using a very old version of Openelec and OSMC and it should be updated, or the wiring (USB) shall be revised.
In the following steps, we will be using a DVB-S2 satellite tuner, as this is the most complicated setup. In case of the DVB-C or DVB-T tuner, the steps are very similar, but usually only one network (the one provided by the cable supplier) will be needed.
If your tuner is there, then we should select the configuration of our satellite system (if you have Diseq switches, Rotors, etc.)
In our case, the satellite reception is fitted with one LNB (responsible of collecting the waves reflected by the satellite dish and down converting them to the 10-12 Ghz range) and a Diseq 1.2 Positioner, that can rotate the satellite dish to the specified location based on the commands received from the TV tuner.
In case a more advanced H-H motor is being used, the configuration is slightly different.
From the Parameters list we should select the Advanced (non-universal LNBs, rotors, etc.) option. In case we have a Diseq 1.1, commanded switch and multiple LNBs, the appropriate option shall be selected.
The 'idle scan' checkbox shall be left unticked, as with the kernels <4.3 can cause trouble with the driver. Also it's not that good to wake up in the night with your dish moving, as tvheadend scans periodically the available Muxes (frequency lists). If you want to update the channel list, you can trigger this manually. The initial scan is a good idea, as will start the scanning right after setup.
Next, we should set up how many orbital positions (i.e. Satellites) do you want to include. In our case, we would like to watch only channels on 0.8W, 19.2E and 28.2E satellites (these contain the Romanian, UK and German channels). This means 3 satellites, so 3 orbital positions. Once you chose the orbital positions, new elements will be added to the list on the left. These can be renamed freely to suit our naming profile.
(See first picture)
this point, it is required to map an orbital position (satellite) to a network.
A little background about why is this necessary:
Tvheadend is a versatile server, and can server various network combinations of DVB-S, DVB-C, DVB-T and IPTV.
In case of DVB-C and DVB-T, usually we have one network, as we have one provider only - i.e. cable provider or terrestrial provider.
But in case of DVB-S, each satellite is seen as a network, therefore for each orbital position we will have to define a separate network.
In our example, for the 3 satellites, 0.8W, 19.2E and 28.2E I we will have 3 networks. Later these will be mapped to each of the orbital positions.
If we would connect a DVB-C or an DVB-T tuner in addition, then we would create a 4rth network, let's say Cable, and map it to the DVB-C adapter.
So in order to add a new network, we go to the Configuration -> DVB Inputs -> Network tab, add a new network (select DVB-S, as we have a satellite tuner attached) and then complete as in the second picture.
this case, we've added a new network for the 0.8W orbital position (satellite)
Here, we need to take care of several things. First, we should add a suggestive name for the network, then select the orbital position. This is necessary to know what Muxes it shall display for that network. These are stored in xml files, usually shall be up-to-date and contain the necessary data. If not, we have to add them manually. For satellite reception, this information can be found here:
For cable or terrestrial reception, the service provider could give this information. If not, then searching on the internet should give some links to forums where this information is found.
Once we select the orbital position, we can also select what Muxes shall be used (i.e. the transponders, as called in the satellite world. This is basically a frequency list - with some additional parameters). Once we are set-up, make sure that the idle scan Muxes checkbox is not checked for the reasons mentioned above.
We have to repeat this procedure to add a network for each orbital position.
Once this is ready, we can go back to the TV adapters tab, and there for each orbital position that we have added (in our example 3), we need to associate the network created previously with this satellite.
From the LNB tab, we select the Universal type, as it's the most common.
If we have a Diseq commanded LNB switch, we select it here, and from the rotor, we select USALS (in case of an H-H motor) or select GOTOX, in case you we have Diseq 1.2 positioner (the one that drives a DC motor to move the satellite dish). In our example the setup has a positioner, so we select the second option. The menu on the left will change to reflect this (see picture nr. 3)
we are ready, we can go ahead and scan the Muxes (transponders). As we’ ticked inital scan, as soon as we add a network, it will start scanning. Usually, Muxes contain also information regarding other Muxes, and the Muxes list will be updated during the scan. If we have configured everything correctly, on the Muxes tab, once the SCAN STATUS tab reaches IDLE (pending means waiting for scan, active means currently scanning and idle means it was scanned already) we should have the Services tab already populated.
In case the SCAN result tab shows error for each of the Muxes, and none are OK, it means it could not lock on those frequencies. The cause will be most of the times that we are not correctly positioned on the satellite. We shall check again on the TV adapters tab that we have configured correctly the rotors, and that the positioner displays the correct stored number for the satellite.
Once we have scanned all the networks, we have to check that the services contain all the channels we are interested in.
We can map all services to channels at once, or we can select one-by-one only those that present interest to us. Pressing the map all button, will bring up a window similar to the one in picture nr. 4.
we’ve just scanned the Muxes, we are not required to tick the first checkbox, as then tvheadend will tune to each channel to verify that it's ok, prior to mapping. This is time consuming and unnecessary.
There is a checkbox, regarding merge same name. This needs an explanation.
The services are different than channel names. We can have a channel, let's say HBO on different satellites from different providers. We can also have HBO on a DVB-C network, and also on 2 different satellites. If we merge them, it will be treated as the same channel, and in case you want to stream, it will choose automatically the network that's available. This is useful in case you have multiple adapters and multiple users.
If we want to see the channels in the classical way (i.e. - to know that a certain channel is on a specific satellite/belongs to a specific provider) we don't tick this.
Sorting the channels is easy, will be explained later.
If we scan a lot of satellites, we will see that we will end up with a big list of channels.
To display all of them in Kodi will make it unusable, as that means thousands of channels.
We need some grouping, like on enigma2 based boxes, based on satellites, providers, etc.
Here comes the help of the Channel tags, accessible from Configuration -> Channel/EPG -> Channel tags.
Basically, once we scan the Muxes, tvheadend creates the channels and will tag them based on some properties, like network name, providers and a lot more.
From this menu, we can select which of the tags we are interested in. For example, we can select the name of the 3 networks we’ve created previously. This will allow us to group them from Kodi client based on the orbital positions (satellites). If we prefer grouping based on providers, we have to select the providers we’re interested in and the channels that have this tag will appear, an only those, once we select this group from the Kodi client. We can also group them based on bouquets, but it's different a bit from what's in enigma2, but if needed, also these could be configured.
At this point, we should be able to stream FTA (Free-To-Air) channels right from the web interface, once you click on the play link from the Services or Channels tab.
Note: It needs VLC for playback, it shall be installed prior to starting the stream.
Step 8: 4 Install and Configure Tvheadend Client Add-on for Kodi
are several clients for tvheadend server. We can view it from Kodi via tvheadend PVR client, but we can also watch it from a mobile phone (Android: https://play.google.com/store/apps/details?id=org... , web browser, etc.
As we are setting up a configuration to act like a receiver, the tvheadend client will run on the same machine (the raspberry pi2) with the server.
In order to install the client, on both OSMC and Openelec, we need to follow Step 4 from the Kodi tutorial below to enable the client:
Go to Settings -> Add-ons -> Enabled add-ons -> PVR Clients and select the Tvheadend add-on Select "Configure" By default, you should only need to fill in Tvheadend hostname or IP address. See the attached picture.
Tvheadend hostname or IP address
The hostname or IP address of the server where Tvheadend is installed. If on the same machine then 'localhost' can be used.
The default for Tvheadend is 9981 but this will need updating if you have changed it in the Tvheadend settings.
The default for Tvheadend is 9982 but this will need updating if you have changed it in the Tvheadend settings.
If you have configured Tvheadend to require a username then enter it here. This can be blank.
If you have configured Tvheadend to require a password then enter it here. This can be blank.
Connect timeout in seconds
The default is 10 seconds however this can be lowered if you want Kodi to timeout connections to the Tvheadend backend quicker.
Response timeout in seconds
The default is 5 seconds however this can be lowered if you want Kodi to timeout requests to the Tvheadend backend quicker.
The material was extracted from the official Kodi Wikipedia:
In addition, the asynchronous EPG update should be also ticked.
A side note:
The SD channels are MPEG2 encoded, while the HD channels are VC-1. Both formats can be decoded by the Raspberry's GPU, but due to licensing issues, this is not available for free on the Raspberry. The good thing is that for a license fee (2-3 GBP) we can purchase both licenses from raspberry's website:
Note: Even is in theory software decoding will be performed in case no license is available, this is practically not usable for watching live content!
After we have the licenses and tvheadend client enabled we should have a new TV entry in the Kodi’s main menu. Clicking on it will open the channel list. If we want so see certain group, we can select them from the left menu. Here, we will get the groups that we have configured previously in tvheadend server, on the Channel tags tab.
Step 9: 5. [Optional] Install Oscam Server to Watch Encrypted Channels
Note: watching encrypted channels is not illegal. Watching
encrypted channels in case you don't have a subscription card is illegal and punishable by law. The severity increases, if you share your subscription card with others. This document will assume that a valid subscription card is being used and owned and that the card is shared only inside the local network. This document is also a proof-of-concept and is intended only for academic use.
Setting up and configuring OSCAM card server is not an easy process, and only the installation part and those related to connecting it with the tvheadend server will be discussed here, due to the note from above. Additional information can be found on the internet.
The Oscam server can be downloaded as a binary from a repository, or can be built from sources. As it’s constantly being developed, it’s better to have it built from sources, as binary builds are usually outdated.
In order to build, additional packages will have to be installed before. The following steps will cover the installation of the build tools, oscam, start stop scripts and automatic update scripts:
a) Install build tools, libs
apt-get -y install apt-utils dialog usbutils
apt-get -y install gcc g++ wget
apt-get -y install build-essential subversion libpcsclite1 libpcsclite-dev
apt-get -y install libssl-dev cmake make
apt-get -y install libusb-1.0-0-dev nano
apt-get install pcscd pcsc-tools
b) Installing oscam from repository
svn checkout http://www.streamboard.tv/svn/oscam/trunk oscam-svn
chmod 755 build
If there are no configuration errors, the make scripts shall be executed:
After installation, a systemd service script shall be created:
Content of file:
ExecStart=/usr/local/bin/oscam -b -r 2 -B /run/oscam.pid -c /var/etc/oscam -p 512
In order to automatically start it at system boot time, the following command shall be executed:
systemctl enable oscam.service
The configuration files shall be placed in the following folder:
mkdir /var/etc/oscamchown osmc.osmc /var/etc/oscam –R
In order to start the oscam server, the following command shall be executed:
systemctl start oscam.service
Now we will create and auto-update script:
The script needs permissions to be executed:
chmod 755 /usr/local/bin/oscam_update.sh
The content of the file:
echo "Started oscam update"
if [ ! -d "$DIRECTORY" ]; then
svn checkout http://www.streamboard.tv/svn/oscam/trunk oscam-svn
if [ ! -d "build" ]; then
# Control will enter here if $DIRECTORY doesn't exist.
systemctl stop oscam
systemctl restart oscam
This script checks out the latest version from the online repository, if there is currently none existing, or will perform an update to the latest files, if it’s already existing, afterwards will try to build the package. In the end, it will stop the currently running version, will install the newly built version and in the end will restart the service.
We can test the script by executing:
In order to run this script periodically, we will create an entry to cron’s task scheduler:
If prompted, we shall select as editor, nano, and once the file opens, we can add the following lines:
#update oscam at 04:02, on 5th day of week
2 4 * * 5 /usr/local/bin/oscam_update.sh >/dev/null
As the server is constantly being developed, it can happen that there are also memory leaks that consume system resources over time. To solve this impediment, we can create an auto restart script:
In order to be able to execute it, we shall set the correct permissions:
chmod 755 /usr/local/bin/oscam_autorestart.sh
The content of the file:
systemctl stop oscam.service
systemctl start oscam.service
We can test the script by executing:
In order to run this script periodically, we will create an entry to cron’s task scheduler:
and add the following lines to it:
#restart oscam at 3:54
54 3 * * * /usr/local/bin/oscam_autorestart.sh >/dev/null
From this point further we will assume that we have a working Oscam server on our raspberry Pi, OR on our internal network, but on different machine. We will elaborate this later on to see why this is also ok.
In order to use oscam to descramble the encrypted channels, we need to make a connection between the tvheadend server and oscam server.
Tvheadend has great support for CAs (Conditional access); we can find the settings under the Configuration -> CAs menu point
What is important for us is the newcamd protocol or the dvbapi protocol.
If we have only one CAID (card id – each provider has at least one card id, but can have also more), then we could use also a newcamd connection between tvheadend and oscam.
As we are assuming that we would like to watch more channel from different providers, we will use the dvbapi protocol, the one widely supported on a lot of Enigma-based STBs.
Before we proceed, some short background info about encryption from wikipedia:
This is achieved by a combination of scrambling and encryption. The data stream is scrambled with an 48-bit secret key, called the control word. Knowing the value of the control word at a given moment is of relatively little value, as under normal conditions, content providers will change the control word several times per minute. The control word is generated automatically in such a way that successive values are not usually predictable; the DVB specification recommends using a physical process for that.
In order for the receiver to unscramble the data stream, it must be permanently informed about the current value of the control word. In practice, it must be informed slightly in advance, so that no viewing interruption occurs. Encryption is used to protect the control word during transmission to the receiver: the control word is encrypted as an entitlement control message (ECM). The CA subsystem in the receiver will decrypt the control word only when authorized to do so; that authority is sent to the receiver in the form of an entitlement management message (EMM). The EMMs are specific to each subscriber, as identified by the smart card in his receiver, or to groups of subscribers, and are issued much less frequently than ECMs, usually at monthly intervals. This being apparently not sufficient to prevent unauthorized viewing, TPS has lowered this interval down to about 12 minutes. This can be different for every provider, BSkyB uses a term of 6 weeks. When Nagravision 2 was hacked, Digital+ started sending a new EMM every three days to make unauthorized viewing more cumbersome.
The contents of ECMs and EMMs are not standardized and as such they depend on the conditional access system being used.
More info here can be found here:
In a nutshell, in the received content we will have to send the ECM to the valid subscription card and get back the decryption key. This means, the tvheadend server needs to communicate with the oscam server, that needs to communicate with the card reader in which there is a valid subscription cards. Now, the part which handles the oscam communication with the cards and/or remote servers won't be discussed here, it's widely discussed on the internet in several forums.
We need to set up tvheadend to send the ECMs and request the decryption keys from the oscam server. As stated before, we will use the dvapi protocol, but unfortunately, we have more variants also here :
a) In the past, the Enigma2 based linux receivers created a socket file, usually in the /tmp folder called camd.socket. Through this socket the CAM (Conditional Access Module) server and the Enigma2 based set-top-box used to exchange data. This has a disadvantage: the CAM server needed to poll for new data every time, therefore this was not a good design. However, this was kept for ages, and, unfortunately this method is widely used as an example on various forums. Fortunately there are better ways now, and, as suggested also on the tvheadend website, the newer one shall be used: http://docs.tvheadend.org/webui/config_caclient/.... Older CAM servers, like CCcam only supports this method. More modern CAM servers, like oscam supports also newer and better methods.
Unfortunately, there is also an older tutorial available on the internet which confuses the user.
b) The socket file was not a good design, due to the problems enumerated above, and oscam implemented the better dvbapi protocols. Now, it can use a TCP/IP based client-server approach (or UDP, but already deprecated) to establish the communication between oscam and tvheadend server. In this case, the server is created on the oscam side, and tvheadend will connect to it as a client, only if necessary. Therefore, there is no polling, and the best part, the oscam server can be on a different machine than tvheadend (still, it should be on the same network and isolated from the outside, as there is no authentication mechanism implemented between them - so anybody can connect).
This means, that even if your tvheadend server is on a different machine, you can request the descrambling keys from oscam without losing one hop. Hops are part of the way the oscam sharing works, also is not in focus of this document. If we wish to use oscam on the same raspberry, we have to install and configure it as described in the chapter above.
Once you have a working oscam server running on your network, we proceed to configure the connection with tvheadend. This can be done also from the oscam server’s web interface manu, , but in the end, we need to end up with the following configuration in the oscam.conf file: [dvbapi] enabled = 1 au = 1 #if you want to pass EMM data for subscription updates pmt_mode = 4 request_mode = 1 listen_port = 9000 user = dvbapi boxtype = pc
Restart oscam, and we should be ready on the oscam server side.
Note: If we run oscam on a different machine than tvheadend, we have to make sure to configure the firewall properly in order to allow TCP connections on port 9000.
On tvheadend side, Under Configuration -> CAs menu point we have to add a new conditional access client, and from the list chose CAPMT (Linux DVBAPI).
Here we will have to set up like in the screenshot attached to this step.
- client name, comment can be anything.
- Mode: this is the tricky part. In order to use the so called mode 5, or protocol version 2, we need to have a slightly new oscam build. This is the supported way also by oscam, other methods will be dropped in the future. So it is highly recommended to upgrade the oscam to a newer version, not to mention that a lot of issues were addressed in these. If you still have to stick with an older version, chose oscam tcp. It’s not recommended to use the old camd.socket method, therefore it won’t be presented here.
- In the screenshot we can see 192.168.1.3, as on that setup, the oscam server is running on a separate dedicated server, and the raspberry's tvheadend is connecting to it. In our case we are running oscam on the same machine (i.e. the RPi2), then we will use 127.0.0.1 as hostname.
- The listen port shall be 9000, as this is the one used in the oscam server. We can change to other value, but have to make sure that the port is free. Also we have to make sure that we change it also on the oscam side, otherwise the connection won't be established.
Once everything is set up, we save the settings and we should see that the connection is established.
1) the debug console on the bottom of the page can be opened any time and we can consult the output it generates.
2) Never ever open the 9000 port to the WAN, i.e. outside your local network. Anybody can connect to it and not only we won’t be able to connect, but strangers can also fraudulently use our server, or even worse, check that we are running on oscam server.
Once this is setup, we should be able to watch scrambled channels, in the same way as we do it on your enigma2 based box.
Step 10: 6 [Optional] Install Additional Unofficial Repositories to Watch Streaming Movies/TV Series
are various unofficial software/add-on repositories available on the internet that will allow us to install Kodi add-ons that allow us to watch the latest movies/TV series that are hosted on various websites. As mostly these also provide unlicensed/pirated content, it won’t be addressed in this document.
As an example, 1Channel, Velocity, Exodus. All of these services support streaming from legitimate sources, but also illegitimate ones. Check the law in your country before watching any channels.
Step 11: 7 Install Lcdproc Server to Handle the LCD Screen
good, professional-looking media center has some sort of display, on which you can see the title and running/remaining time of the currently running movie, the name of the currently playing online radio station or the name of the currently playing music.
In order to equip the media center with such an LCD, first it must be wired accordingly. The LCD that was chosen is a Vacuum Fluoride Display, almost pin-compatible with the Hitachi HD44780 displays and 100% compatible at register-level.
The VFD has an advantage over conventional LCDs, as it is brighter easier to read in direct sunlight, has blue-greenish color that looks professional and still has good power consumption (150mA).
The LCD has an 14 pin header which we will use to connect it to the raspberry PI’s 40-pin header.
The VFD can be wired to the raspberry using the following connections (on the left is the VFD header, on the right you can see the GPIO port of the raspberry PI2. Attention shall be taken, as the GPIO pin numbering is different from the pin numbering of the 40-pin header): D7=22, D6=27, D5=17, D4=23, RS=25, EN=24
(See the attached picture nr. 4 with the Rpi 40 pin connector header)
RW pin must be connected to GND, as the PI’s GPIO ports are 3.3V tolerant only. The VFD will work if it’s supplied with 3.3V only, but if the RW pin is not grounded, it will also try to communicate on the same ports. This can lead to damaging of the raspberry PI’s port, as the VFD is supplied with 5V.
The VCC of the VFD shall be wired to 5V (it’s not advisable to use the 5V on the raspberry, as the 150mA current consumption might be too much to handle, even if other USB devices are connected, therefore it should be powered directly from the external power adapter that supplies also the Raspberry PI2).
All GNDs shall be connected together, therefore the GND pin (1) of the VFD shall be connected to one of the GND pins of the 40-pin header (PIN6, for example).
After the HW wiring is done, the necessary software shall be also installed in order to make it work.
Fortunately, there is no need to write low-level pin addressing software, as there is already a good open-source software package available, that can handle various displays, also the one chosen by us, called lcdproc.
This also has a client-server architecture, meaning that the lcd server can communicate via the display and also via clients using TCP/IP protocol. Kodi also supports the lcdproc server via and Add-on.
To install the lcdproc server, from the console session the following commands shall be executed:
sudo apt-get update
sudo apt-get install lcdproc lcdproc-extra-drivers
select "Yes" perform auto config upgrade The official hd44780.so driver at the time of writing this document does not support the raspberry pi2, as the address of the GPIO port has been changed since the PI1. Due to this, an updated driver is needed. This can be compiled from the sources posted in the thread below, or the binary provided could be also used. The second is the better choice, as there’s no need to build lcdproc from sources.
The lcdproc server has to be configured to support the VFD. The /etc/LCDd.conf file shall be edited to have the following settings:
DriverPath=[Shall be left unchanged]
## Hitachi HD44780 driver ##
# Select what type of connection. See documentation for types.
Once the lcdproc server is installed, the LCDProc client shall be also installed from Kodi’s menu:
Settings >> Add-ons >> Get add-ons >> XBMC/Kodi add-on repository >> Services >> XBMC LCDproc >> Install
Step 12: 8) Install Lircd Server to Handle the IR Events
If the TV supports CEC protocol over HDMI, then the TV’s remote control shall also work in Kodi. If the TV doesn’t support his, then we can use an usb mouse (preferably wireless), a mobile phone application, like Yatse, or we can connect an 3.3v IR receiver to the GPIO18 pin of the raspberry. The Hardware chapter describes the type of IR receiver to be used. In oder to support the IR receiver, the appropriate kernel module shall be loaded. This can be done either by adding the lirc_rpi module to the /etc/modules, or from the OSMC’s or Openelec’s configuration menu it can be selected graphically. After restart, we can check that above kernel module is loaded.sudo lsmod | grep lirc_rpi
We should find a line in dmesg that says:
sudo dmesglirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0 [68648.951805] lirc_rpi: driver registered!
Also, we can check that Linux has created a device file to represent the infrared device hardware.
sudo ls -l /dev/lirc*
The IR Receiver device file is /dev/lirc0.
Note: The licr_rpi module STOPPED working with recent kernel updates. In this case, the following shall be added to to /boot/config.txt:
and the lirc_rpi shall be removed from /etc/modules
To teach a new remote control, first you need to kill the running lircd process:
Next, we need to run the following command to export the available keytable:
ir-keytable -p LIRC
Then we have to start irrecord telling it where to create the new config file:
Next, we will use the keytables exported above and teach the new remote, following the on screen instructions. (like KEY_POWER and so on.)
After teaching the remove, the raspberry PI shall be rebooted.
Troubleshooting in case there is no Response during learning:
We can running irw to see if you get any input at all:
,while pushing buttons.
If we don't see any output then the remove is not correctly wired.
Step 13: 4K,HEVC and 10 Bit
Like I've already said, the only drawback of the Raspberry PI3 is the lack of support for 4K and HEVC decoding.
After a long study, there seems to be an almost viable replacement for the PI: Odroid C2 by Hardkernel.
This has an AMlogic s905 ARM 64 CPU and a MALI-400 GPU with 2GB RAM, Gigabit ethernet and capable of HDMI 2.0, 4k resolution and HEVC decoding. Just the perfect board. And you can buy it for ~50 dollars, if you're lucky and get it on sale.
Here's the full specspec:
Before jumping to the internet and buy it, please consider the following limitations:
- Has way less support than the PI
- Has an ancient (3.14 kernel), therefore a lot of new devices are not supported out of the box.
- USB power output seems to be less than the RPI3 can handle, therefore I had problems with the tv tuner. After cutting the USB connector and supplying it directly with DC 5V, the problems seems to be resolved.
- Kodi images:There is no image like OSMC available for it, supporting Kodi out of the box and having a full debian distro underneath.
You can choose instead from the following distros:
Ubuntu (with desktop), DietPi (this could be close to OSMC, but it's very complicated to install Kodi on it and will still install X, see below the problems), Archlinux (you need linux to flash it to a card) and Android.
Android is out of question, if you need support for tv tuners.
The ubuntu and debian distros are full desktops (except the Dietpi, which comes as a minimal package), and, even if you install Kodi on them, they will run under X and the performance is quite poor. There seems to be no framebuffer support for Kodi.
When installing Kodi on DietPi, it starts to update and after around 3 hours it still downloads packages if you try to install Kodi from the menu.
When I saw that it still installs the full X.org system, I did not countinue. So if somebody has experince with this, please feel free and share it.
The only remaining option, and the best, for now is to install the lightweight, well-known LibreElec distribution.
Kodi is supported and there are no major problems with it. Passthrough works, 4K, HEVC decoding as well, it has tvheadend 4.2 , oscam and everything available for download from some not so official repositories.
It can be downloaded from here:
In this case, the Sundtek tuner will work out of the box, but the DVBSkY not so likely.
In this case, as of end of 2018, the CoreELEC team:
has put together images that work very well with Amlogic chipsets, therefore with the Odroid too. To recognize the other tuners, chose from the addon menu the Dvb drivers provided by CrazyCat for TBS cards. This actually has many more tuners supported, among those is the Dvbsky as well.
So do you need the Odroid C2 instead of the Raspberry Pi3 ?
- If you don't have a 4K TV anyway
- If you don't want to watch those 10-20, mostly demo channels available today
- If you prefer to have good support
- If you have a 4K capable TV and you watch content downloaded from the internet mostly, and not live tv
- You like to search for answers on forums etc.
Note: After changing the Raspberry to Odroid C2, I've also made several changes to the HW setup, as seen in the picture:
- Installed an 5V DC-DC converter, capable of supplying 5Amps, and replaced the dual 12V/5V power supply with just one single-output, DC 12V supply. The converter will supply the 5V for the odroid, USB Hub and the TV Tuner.
- Replaced the Coaxial cable with one plain one.
- Added an I2C backpack for the VFD and connected it to the Odroid via i2C.
You can buy one for 1-2 bucks from a lot of places.
I've used one of these:
Also, when choosing a tv tuner, in case you have an Odroid C2, it's better to chose the Sundtek. It has much better support, and the driver is more stable.
More than that, it seems that the Odroid has poorer USB drivers, and with high bitrate channels, I could experience some transport errors on tvheadend and the image was stuttering.
After endless forum browsing, I found that it's due to the USB speed, and it could help to activate in the 'sundtek.conf' file the HW PID filter.
This will reduce the bandwidth usage and will solve (most) of the problems.
After the Odroid N2 was released, this became very quickly a better alternative to the Odroid C2. It's faster, has HDR and USB 3.0. As this article was already too big and also the whole thing was built from scratch, I've created a follow-up to this one:
Step 14: Advanced Setups: Multiple Tuners, H-H Motors
Normally, for just one TV set, you don't need more than one tuner and most of the time you won't have a motorized dish or you'll have a positioner.
In case of using multiple tuners (in case you want to watch simultaneously multiple broadcasts (see below for restrictions) some additional setup is needed.
Also, in case of using a H-H motor, you have to make sure that the 'Turn off LNB when idle' is unchecked. Otherwise, the dish will stop moving after ~10s or so as vlc or Kodi will retry to request it and the dish won't reach the desired satellite position all the time.
Also note that while the Sundtek tuner will power down the LNB output after a while, the Dvbsky seems to keep the output powered also in case the output is inactive, even if the 'Power save' option is checked on both tuners (in the Configuration panel).
In case of using multiple tuners to the same dish and LNB, you have to make sure to set one of the tuners as slave, as otherwise both will try to switch polarity or send Diseq commands to move the dish.
In case one of the tuners are set as slave, tvheadend will make sure that it won't allow incompatible requests that can lead to such situations (i.e. When one of the tuners is busy on one satellite and one polarity, the other tuner will be allowed to 'stream' only from the same satellite and same polarity.
In case you have a Diseq switch, it's not necessary, but then you will have to configure the switches accordingly in the 'Dvb Inputs' -> 'Tv adapters' section.
Also in case one of the tuners is connected to a separate dish then it must not be set as slave tuner.
1) Using more than one DVB tuners simultaneously on the Raspberry PI is a bit of an overkill, as the Ethernet adapter and USB are both handled via the same USB bridge. In this case you'll have to use an Odroid C2, which has 1 Gbps ethernet and USB speed is also higher.
But if you have an DVB-C/T tuner and also a DVB-S tuner and you don't intend to use them simultaneously, then the Pi should have sufficient horsepower to handle this.
2) Multiple tuners mean more power consumption. Make sure that the DC-DC converter and the 12V power supply can handle the current needed by the Raspberry/Odroid C2 and rest of the electronics. It's recommended to supply the tuners from a powered USB hub.
Step 15: Conclusion
The media center that we’ve built
provides access to music, movies stored locally on USB-attached hard drives or pen-drives, but can also provide streamed content via additional add-ons that are installed from various software repositories.
The raspberry PI2 has quad-core processor, therefore it’s fast enough to fluently run the Kodi media center. The included GPU is capable of HW decoding the H.264 content, and with additional MPEG2 license, it ca also decode DVD movies or DVB broadcasts in SD format.
Attaching a supported DVB-S/S2, C, or T/T2 TV tuner will also enable the watching of live television.
The GPIO header of the raspberry Pi allows the connection of an external LCD/VFD and additional input keys (if needed).
How Future-proof is this set-up?
The Raspberry Pi is a good choice for a media center that holds 1080p H.264 encoded content. Activating pass-through feature can further extend the audio-capabilities, as connecting a digital AV receiver that can handle DTS, DTS-HD, and AC3 audio content will off-load the CPU from decoding this type of content.
Also, there are several add-on boards, like HifiBerry, that will add also optical or analog 5.1 channel output.
4K, 10 bit and H.265 content?
Once the 4k resolution, 10 bit/channel wide color format and H.265 or HVEC encoding algorithms become mainstream, the Raspberry PI2’s hardware won’t be powerful enough to handle these formats. This segment is slowly evolving, and looking back at the SD -> HD transition, we are still years behind the days when 4k content will be widely available.
Still, today you can already buy media players based on the Amlogic S905 or S912 chipsets or the Odroid C2 board , which already offer support of 4K@60Hz, 10 bit colors space and HDMI 2.0 ports.
The price range is also accessible, however the software support is still behind, as currently these boxes are running some dumbed-down versions of Android or distros with and old kernel.
The best candidate for a future media center would be an Odroid C2, which has an Amlogic S905 CPU capable of all the features enumerated above. It also has a full debian distro, but still there are some problems on the driver side. As of first quarter of 2016, the DVB support is still problematic, therefore you will have to read a lot on the forums to get the USB tv tuner to work on it. Hopefully as the development is still ongoing, this might change in the not so distant future, therefore you should keep an eye on it.
Step 16: Bibliography