Project: Building a DVB-T TV Tuner Server with mumudvb

Building yourself a TV tuner server is definitely not a new thing for me. In fact, I did this almost precisely one year ago with mumudvb. Since then, I have learnt a few bits of wisdom and needed to start replacing some parts and upgrade the software to something more modern. In some ways, it was like starting a new build, so I thought it would be good to get a little bit of knowledge out there in case anyone was interested in running one for themselves.

Given that the digital TV switchover is coming really soon – maybe it’s something you might consider doing too?

What is a TV Tuner Server?

A TV tuner server is a computer on your network which is attached to a number of TV tuners. These tuners are tuned into the multiplexes (physical channels) which carry your TV services (virtual channels) and provide the raw Transport Stream (data) for mumudvb (the server software) to serve to clients (computers) on the network.

It doesn’t do more than just this – it doesn’t record TV for you, it doesn’t magically inform you what’s on and remind you to tune into a given series. It’s merely a way of “sharing” your pool of TV tuners across a network.

Why might you want this?

One very common scenario, and one that is the case with me, is that there is simply a lack of TVs around the house and a lack of TV sockets. Even if we purchased new TVs, they’d have nothing to plug into and indoor aerials just don’t work well enough right now.

You may already have a large cabled network and computers in most rooms – why not turn them into TVs “on demand”? You’ll get as good a quality as you will otherwise get, as the server itself (by default) does no transcoding of the video and audio and the bandwidth requirements are very reasonable (compared to the speed of a gigabit network, for example).

It also means no more fighting – after all, if you have enough tuners, everyone can watch whatever they want at any time, although (to my knowledge) for a mumudvb set-up, each tuner will be fixed to one channel and won’t be dynamically “re-allocated”. The great part is that it’s all open-source, and it’s all free (although, donations are definitely advisable).

Products which do something similar are already available, one of the most popular being the Silicondust HD HomeRun and the Elgato Netstream DTT. They both appear to be rather special software-bundled network tuners, they do have bells and whistles in being specially adapted for use with tablets and mobile devices, however they seem rather closed and not to mention, expensive ($299 or so) given the number of tuners in them (mostly two).

You could do much better, if you just did it yourself.

What do you need?

What you need really comes down to what you want to accomplish. The first thing you will need is a computer. Depending on whether you want the computer to also be a client so it can be used as a TV or not will dictate the specifications needed. In my case, I had the server at the kitchen table, and we wanted it to be a TV as well, so something more decent was required.

In the end, my server is built using an AMD Sempron 145 (with the second core unlocked), and an old Asrock N68S-UCC (Nvidia chipset) based motherboard. The onboard graphics were used to connect to an old monitor as the “TV”, and it happily runs a VLC player instance as well as six mumudvb sessions (one for each tuner) without any signs of distress. With that in mind, you should be able to get decent results with even old hardware, but for reliability and “background” power consumption, my advice would be to go for relatively low-end modern hardware if you’re looking to build new.

The key things to look out for in the hardware include the availability of a Gigabit Ethernet port. It’s not essential, but it could be desirable under heavy loading. Each HD channel can peak at about 14Mbit/s, and SD at about 8Mbit/s, so with a 100Mbit/s connection, it’s likely to be swamped by 8-10 viewed channels simultaneously (in the worst case). It’s typically enough for a family, but not more. Upgrading to a Gigabit card would give you more headroom and less things to worry about.

It could also be possible to run this on various ARM based low-power computing devices, but I haven’t tried it. It’s my assumption that their bandwidth handling isn’t going to be up to the task of handling a large number of tuners, so if you’re serious about running this – avoid using them. Also, it’s unlikely that the distributions for those would include V4L either, so you will have to build it yourself (more hassle, and I’ve always been lazy).

The operating system will need to be a variety of Linux. I personally recommend Lubuntu. It’s a Ubuntu derivative which has LXDE substituted for the “overweight” Unity desktop, and is a Debian derivative. Thanks to being Linux, it is free, reliable and open source. I couldn’t imagine a life without it. Most packages are available and administration is easy. As of the 13.10 release, a very recent V4L (Video 4 Linux) build is already included – one which supports even RTL2832U TV tuners with R820T front ends! Hallelujah!

RTL2832U+R820T Full Size Tuner Stick Front

Those looking to run older tuners are in luck as well – the Twinhan VP7045/7046 tuners can be run just by grabbing the linux-firmware-nonfree package. The remote control receiver seems to be somewhat bugged, and when the tuner is open, tab characters are sent to the input as if someone pressed the tab key once a second. A fix, appropriate for mumudvb servers, is to disable the IR receiver altogether by following these instructions.

VP-7045A Tuner

Those with even older Vstream VS-DVBTUSBII “300” series tuners (such as the one below) can grab the firmware from this ZIP file, unzip the file and move the dvb-usb-adstech-usb2-02.fw file to /lib/firmware. I never thought it could be that easy to get some of these old veterans going again …

Old Vstream Tuner

If your TV tuner isn’t supported by the included V4L drivers, you may need to build the latest V4L from source, or download and build the drivers provided by your manufacturer (if any). So I suppose, for some of you, this could give new life to old tuners which see no use possibly because their Windows driver support is a bit crook. If you haven’t got any TV tuners, or need some, getting the RTL2832U + R820T’s are a great idea as they are inexpensive at $11 each, and generally cause no trouble.

For Sydney, Australia, we have six DVB-T multiplexes, so it’s advisable that if you wish to view any of the channels on air that you have six DVB-T tuners. You will need a set of quality USB hubs to accomodate the required number of tuners – I recommend looking for hubs with good port spacing that doesn’t place ports directly next to each other as the tuners will not physically fit. Hubs that place tuners one on top of the other or at 90 degrees tend to work well. Four port hubs can be used, without external power even in my experience, although a powered hub always makes for better reliability. I don’t think you should put more than about eight tuners per USB controller (remember, your computer may have 6/8/10 USB ports, but all are fed from the same root hub and share the same controller’s bandwidth). Consider installing more USB controllers (i.e. PCI-E to USB 3.0 cards for example) if you require more tuners.

You can easily extend the concept to DVB-S/DVB-S2 satellite tuners (although the mumudvb configuration is more complicated), so keep this in mind.

Now, you need to think about the appropriate parts needed to get the RF signal to where it needs to go. For the case of terrestrial, with a large number of splitters, it is not possible to do this without amplification. I advise readers stay away from cheap eBay equipment from manufacturers like Xiamen Seebest. They make many cheap splitters and amplifiers, but I’ve had poor results from them – part of the annoyance is that the F-connectors on them are not of the standard F connector size, so only their supplied push-on F-connectors will thread onto their amplifiers and splitters. None of my third party F-connectors that work on everything else will mate with them – and attempting to do so by force strips the threads from the connector. Visually, it’s hard to distinguish, but trust me. I’ve known because I’ve made this mistake, twice. Aside from this, I also find their performance to be very marginal – I am very skeptical of the frequency range and gain figures, especially having opened one of them and finding pairs of ports sharing what appears to be a transistor output stage. Remember, feeding a server a bad signal means everyone’s unhappy.

Xiamen SeebestUnfortunately, this means you will have to spend a fair amount of money on a quality distribution amplifier. You will need to get the appropriate cables and adapters to connect the distribution amp to each of your tuners (e.g. F to F lead + an F to MMCX adapter for newer mini tuners or to PAL/Belling Lee for older tuners). You will need to connect the distribution amp to your wall (depending on socket, this could be an F to F lead, or an F to F lead with an F to PAL/Belling Lee connector). If you’re handy (as I am), you can easily use compression fittings and make your own F-to-F leads with quality RG-6 Quad Shield to ensure no “stray” signals cause trouble. Otherwise, you may spend a fair amount buying short jumper leads made with single, double or triple shield coax which is inferior (but still, unlikely to cause much trouble due to the short cable distance).

MMCX F

Whatever you do, don’t forget to buy F terminators for unused ports of your amplifier (unless it is of an auto-terminating type). If you leave ports unconnected, this means signal reflections and standing waves which cause signal problems throughout the system.

F terminator

In the end, my system looks like this:

mumudiagram

Finally, the last piece of the puzzle (or one of the last pieces), is the mumudvb software itself which can be downloaded from here. First ensure you have the build-essentials package by running sudo apt-get install build-essentials. You will need to extract the file, and run ./configure before make and sudo make install as usual.

Multicast or Unicast?

If you haven’t guessed it already, the “mu” in mumudvb refers to multicast. It’s an IP packet mode which allows for the same packets to be multicasted (i.e. sent to multiple endpoints) at once. The server merely has to send multicast frames, and everyone interested will receive a copy of it – the server doesn’t have any additional workload if 10 or 100 viewers were watching.

Unfortunately, multicast requires network infrastructure support in the form of smart switches that support IGMP Snooping. IGMP (Internet Group Management Protocol) is a way which clients can “signal” upstream devices of their interest in a given multicast stream. Only those ports which have received an IGMP request will receive the multicast packets corresponding to that address, preventing uninterested ports/clients from being flooded with traffic they’re not interested in.

Most home networks are built with dumb routers, switches and access points which treat multicast traffic as broadcast traffic. If you configured multicasting on those networks (e.g. the one at my house), each port could easily receive 100+Mbit/s of traffic they weren’t interested in, and wireless APs will become saturated with multicast traffic they need to send at basic rate (typically the lowest supported rate to ensure everyone in range will receive it – e.g. 1Mbit/s). VoIP adapters which run at 10Mbit/s will not have any chance to speak, and the network will die.

Instead of this, we can use a “still in trial” HTTP Unicast mode. This means the server sends streams out as TCP packets (rather than UDP multicast packets) and handles each viewer individually. Ten viewers watching the same channel will mean the server has to send ten copies of the same data out of its network port. This one-to-one correspondence allows for the uninterested parties to remain “quiet” and not be bothered by the TV traffic.
I’d say most home users will be most interested in HTTP Unicast due to network requirements. It makes the most sense for a home network as it’s unlikely everyone will have all switches and access points with IGMP Snooping capability (and for it to work without bugs!).

Testing and Configuration

The software is very powerful, the full list of capabilities is extensively covered in the documentation which is available online. In order to make things as simple as possible, I’ve opted to use the full autoconfiguration mode – you don’t really need to know what that means just yet.

The first step to seeing if mumudvb works at all is to see if it can list your tuners. By using the command mumudvb -l, mumudvb should list all connected tuners. If your tuner does not show, try checking dmesg for hints about why the device wasn’t recognized – maybe it is having trouble with the USB bus or needs firmware (this was mentioned in the What do you need? section earlier).

MuMuDVB Version 1.7.1
 --- Build information ---
Built without CAM support.
Built without transcoding support.
Built with ATSC support.
Built with support for DVB API Version 5.
---------
Originally based on dvbstream 0.6 by (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://mumudvb.braice.net/
Project from the [email protected] (http://www.crans.org)
by Brice DUBOST ([email protected])

Info:  DVB:  ==================================
Info:  DVB:          DVB CARDS LISTING
Info:  DVB:  ==================================

Info:  DVB:  =========== Card 0 - Tuner 0 ===========
Info:  DVB:   Frontend : DiBcom 3000M-B DVB-T
Info:  DVB:   Terrestrial (DVB-T) card
Info:  DVB:   Frequency: 44250 kHz to 858000 kHz
Info:  DVB:

Once your cards are listed, you’re almost ready to go. The next step is to author a configuration file. A very basic configuration file that I use which configures the bare “minimum” for my needs is as follows – feel free to tailor it to your needs:

card=0
freq=571.500
bandwidth=7MHz
autoconfiguration=full
multicast=0
multicast_ipv4=0
multicast_ipv6=0
unicast=1
ip_http=0.0.0.0
port_http=4028

It should be all pretty much self-explanatory – card refers to the tuner number we want this configuration file to be directed at, freq is the frequency that the card should be tuned to, bandwidth refers to the DVB-T carrier bandwidth (needs to be stated as mumudvb defaults to 8Mhz). autoconfiguration set to full allows for mumudvb to automatically discover services on the multiplex and make them available, while multicast allows you to switch on/off the multicast feature and set the address. unicast is used to switch on/off the unicast feature, ip_http configures the interface to bind to (in this case 0.0.0.0 means all), and port refers to the port used to do the unicasting.

Before letting it rip, I should suggest that you configure your server with a static IP address, so clients know where to find it. You can do this in Lubuntu by using the network configuration icon near the system clock.

On my network, I have decided to configure the server instances all at port 40xx where xx is the former analog channel number – e.g. 4002 is ABC, 4007 is Seven, 4009 is Nine, 4010 is Ten, 4028 is SBS and 4031 is TVS (or community TV). The TV server is allocated a static IP of 192.168.0.11. As you can see, the config file above is for SBS. This information should help you make sense of the playlist files which follow.

To start a mumudvb server one-time, you can just issue a command like mumudvb -d -c mumutuner0.conf assuming that your configuration file is called mumutuner0.conf in the current directory. This starts mumudvb in a non daemonized fashion.

If you’re a bit more sophisticated, you should investigate the whole concept of pidfiles and daemons, and getting it to automatically start on boot-up, but since my server fails so rarely, I haven’t done this. Instead, I merely wrap the above command in a shell file that restarts the process after sleeping 5 seconds to “recover” from transient tuner problems.

This should be kept in mind as well – those using the VP7045/7046 tuners may find that they fail to tune the first time mumudvb tries. This is not a problem, as the second tuning should work just fine.

When mumudvb starts in autoconfiguration mode, you should see a list of services after a short 5-10 second delay as it waits for the SDT to be broadcast over the frequency. If you don’t get this and instead get an error about using partial service tables or something like that, it’s a sign that your reception is in trouble. You should look into documentation to get mumudvb to report the signal level for your troubleshooting.

In the case of my old Vstream Dibcom based tuner, seeing a non-zero Bit Error Rate (BER) figure appears to be a driver thing, the reception is okay and there’s no cause for alarm.

If all is good and the service list comes up, you should be able to navigate to localhost:<port>/channels_list.html and see the list of channels, and launching any of the links using VLC should let you watch the channel! All of the channels will be listed in /bysid format because of the use of full autoconfiguration.

Channels List

You will need to do this for each multiplex/tuner you want to serve.

Mumudvb Clients

In theory, anything that supports streaming a transport stream from a HTTP source can be a client.

The most popular, and free client, is VLC Media Player. It’s available virtually everywhere, and its initial use (VLC standing for Video LAN Client) was for networked video. What a nice fit that is! It’s capable of easily tuning into uni and multicast streams, although it’s a bit fussy over wireless.

In order to use VLC, one merely has to open the URL corresponding to the channel (e.g. http://192.168.0.11:4007/bysid/1312) from the channels list (e.g. http://192.168.0.11:4007/channels_list.html). This can get quite tiring quickly, so it’s best to set up a playlist with all your channels and instead navigate to the playlist to change channels.

VLC Playlist

The simplest is to write your playlist as an Extended M3U format playlist and have this “hosted” on the same computer you’re running mumudvb on (e.g. by installing lighttpd) or on an external server (my website for example: http://goughlui.com/tv.m3u). This can pay dividends if you’re using the playlist with other clients.

#EXTM3U
#EXTINF:0,ABC News 24
http://192.168.0.11:4002/bysid/544
#EXTINF:0,ABC1
http://192.168.0.11:4002/bysid/545
#EXTINF:0,ABC2 / ABC4
http://192.168.0.11:4002/bysid/546
#EXTINF:0,ABC1
http://192.168.0.11:4002/bysid/547
#EXTINF:0,ABC3
http://192.168.0.11:4002/bysid/548
#EXTINF:0,7 Digital
http://192.168.0.11:4007/bysid/1312
#EXTINF:0,7 Digital 1
http://192.168.0.11:4007/bysid/1313
#EXTINF:0,7TWO
http://192.168.0.11:4007/bysid/1314
#EXTINF:0,7mate
http://192.168.0.11:4007/bysid/1315
#EXTINF:0,7 Digital
http://192.168.0.11:4007/bysid/1316
#EXTINF:0,TV4ME
http://192.168.0.11:4007/bysid/1319
#EXTINF:0,Nine Digital
http://192.168.0.11:4009/bysid/1057
#EXTINF:0,GEM
http://192.168.0.11:4009/bysid/1058
#EXTINF:0,GO!
http://192.168.0.11:4009/bysid/1059
#EXTINF:0,EXTRA
http://192.168.0.11:4009/bysid/1060
#EXTINF:0,ONE
http://192.168.0.11:4010/bysid/1569
#EXTINF:0,TEN Digital
http://192.168.0.11:4010/bysid/1573
#EXTINF:0,ONE
http://192.168.0.11:4010/bysid/1575
#EXTINF:0,ELEVEN
http://192.168.0.11:4010/bysid/1576
#EXTINF:0,SBS ONE
http://192.168.0.11:4028/bysid/769
#EXTINF:0,SBS TWO
http://192.168.0.11:4028/bysid/770
#EXTINF:0,SBS 3
http://192.168.0.11:4028/bysid/772
#EXTINF:0,SBS 4
http://192.168.0.11:4028/bysid/773
#EXTINF:0,SBS HD
http://192.168.0.11:4028/bysid/774
#EXTINF:0,TVS
http://192.168.0.11:4031/bysid/44

But if you want to tweak VLC a little more, the best playlist format is XSPF which looks like this, as it allows you to tweak the network caching period (in milliseconds) which may help with stability with times, or hurt it. This one was generated for an older deployment of mumudvb before Sydney’s Freeview gained a few channels – play at your own risk/desire.

<?xml version="1.0" encoding="UTF-8"?>
<playlist xmlns="http://xspf.org/ns/0/" xmlns:vlc="http://www.videolan.org/vlc/playlist/ns/0/" version="1">
    <title>Playlist</title>
    <trackList>
        <track>
            <location>http://192.168.0.11:4002/bysid/544</location>
            <title>ABC News 24</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>0</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4002/bysid/545</location>
            <title>ABC1</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>1</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4002/bysid/546</location>
            <title>ABC2 / ABC4</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>2</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4002/bysid/547</location>
            <title>ABC1</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>3</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4002/bysid/548</location>
            <title>ABC3</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>4</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1312</location>
            <title>7 Digital</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>5</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1313</location>
            <title>7 Digital 1</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>6</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1314</location>
            <title>7TWO</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>7</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1315</location>
            <title>7mate</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>8</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1316</location>
            <title>7 Digital</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>9</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4007/bysid/1319</location>
            <title>TV4ME</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>10</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4009/bysid/1057</location>
            <title>Nine Digital</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>11</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4009/bysid/1058</location>
            <title>GEM</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>12</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4009/bysid/1059</location>
            <title>GO!</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>13</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4009/bysid/1060</location>
            <title>EXTRA</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>14</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4010/bysid/1569</location>
            <title>ONE</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>15</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4010/bysid/1573</location>
            <title>TEN Digital</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>16</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4010/bysid/1575</location>
            <title>ONE</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>17</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4010/bysid/1576</location>
            <title>ELEVEN</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>18</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4028/bysid/769</location>
            <title>SBS ONE</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>19</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4028/bysid/770</location>
            <title>SBS TWO</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>20</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4028/bysid/772</location>
            <title>SBS 3</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>21</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4028/bysid/773</location>
            <title>SBS 4</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>22</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4028/bysid/774</location>
            <title>SBS HD</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>23</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>                
            </extension>
        </track>
        <track>
            <location>http://192.168.0.11:4031/bysid/44</location>
            <title>TVS</title>
            <extension application="http://www.videolan.org/vlc/playlist/0">
                <vlc:id>24</vlc:id>
                <vlc:option>network-caching=1000</vlc:option>
            </extension>
        </track>
    </trackList>
    <extension application="http://www.videolan.org/vlc/playlist/0">
            <vlc:item tid="0"/>
            <vlc:item tid="1"/>
            <vlc:item tid="2"/>
            <vlc:item tid="3"/>
            <vlc:item tid="4"/>
            <vlc:item tid="5"/>
            <vlc:item tid="6"/>
            <vlc:item tid="7"/>
            <vlc:item tid="8"/>
            <vlc:item tid="9"/>
            <vlc:item tid="10"/>
            <vlc:item tid="11"/>
            <vlc:item tid="12"/>
            <vlc:item tid="13"/>
            <vlc:item tid="14"/>
            <vlc:item tid="15"/>
            <vlc:item tid="16"/>
            <vlc:item tid="17"/>
            <vlc:item tid="18"/>
            <vlc:item tid="19"/>
            <vlc:item tid="20"/>
            <vlc:item tid="21"/>
            <vlc:item tid="22"/>
            <vlc:item tid="23"/>
            <vlc:item tid="24"/>            
    </extension>
</playlist>

In fact the playlists are not yet properly complete as I haven’t yet installed and enabled my TVS tuner (port 4031) yet, awaiting a new high quality distribution amp, so selecting that channel won’t work at the moment.

It’s also important to note that mumudvb does have some other URLs you can use for special purposes – you’ll have to do some documentation digging to find these out :).

Of course, VLC is hardly a one-size-fits-all solution. It hasn’t got any support for timeshifting (despite what the buttons and time slider might mislead you into thinking) for example, and its slightly clunky TV interface.

One of the alternatives is ProgDVB which is a highly respected tuning application for direct connected tuners and IPTV usage.

ProgDVB

Their free, but closed-source Windows client, supports timeshifting and viewing just fine, if you install it with the IPTV client alone and configure the IPTV client to get its playlist from a webserver in .m3u format. This is why I suggested you host it on the machine running mumudvb as well, and to use m3u – I don’t think ProgDVB will read local playlists.

IPTV-Client

Upgrading to the paid version brings you recording abilities as well. ProgDVB apparently supports multicast too if you’re interested, but lip sync issues can arise. You’re highly recommended to install third party MPEG-2 and MPEG-4 codecs, say via K-Lite Codec Pack (rather than rely on the trial Elecard codecs which expire).

It may sound wacky, but even wget or cURL can be made into a client in the sense you can use it to dump a transport stream from the server to a file (as a recording). On Windows, with Free Download Manager, it’s possible to input the URL to a stream and set start and end times, and configure it for one-part, no-retry operation as a recorder.

It’s possible to use mumudvb with XMBC and MythTV, although I don’t personally use it, I would suggest that you do some experimentation and see what works.

One thing I do have to say is don’t bother with trying to stream to clients over wireless – it’s just not sensible. Multicast on most networks will clog everything up (as the wireless APs typically use basic rate – i.e. the lowest data rate – to send multicast/broadcast frames), and unicast suffers from the variability and retransmission of TCP frames. My experience is that VLC very soon chokes on wireless complaining of garbage data or lost synchronization (not because buffers are lost, but because the network stream delay jitter is too much) and while ProgDVB behaves better, it too cannot manage a long session without eventually garbling up.

Likewise, it’s possible to connect to the stream on an Android phone or tablet, using vPlayer (and there was just one player on iOS which was capable as well) but the same caveats apply. In short, this solution is best used for wired users only.

That being said, if you had a more powerful machine, you could opt to run VLC sessions to do live transcoding for “reduced bandwidth” streams friendly for mobile devices and make that problem go away as well.

Conclusion

Given how powerful computers are, and how fast networks are, an IP converged services system for the home is a great idea. It minimises the variety of cabling required and has the potential to offer good service quality to many clients at once. Each client can view whatever he or she wants, and however many channels as bandwidth can allow. There’s no more conflict and fighting about what channel to watch – and reception stability is equal for everyone.

The one drawback is the use of energy, 24/7, to run the server. But as per every other “IP” service, be it telephony, file and print services, is considered essential to the network, so is this. It’s another convenience that I have “built” myself using freely available open-source tools that I have grown to love.

Of course, if it was more integrated with its clients, it would be nice – but it’s definitely more capable, flexible and cheaper than pre-built solutions. If you have a few tuners lying around, and an old PC, it could be something you could come to enjoy as well. It doesn’t take as long as you might expect to get it working.

About lui_gough

I’m a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!

This entry was posted in Computing and tagged , . Bookmark the permalink.

18 Responses to Project: Building a DVB-T TV Tuner Server with mumudvb

  1. swiftpint says:

    Nice guide!
    Quick question. In the playlist section, your VLC screenshot shows a massive list of lots of channels. How are you setting up the mumudvb conf file to point to all of those channels?
    I cant find any advanced information on the conf side of things, at the moment my channels_list.html looks very similar to yours, with only channels from one frequency shown.

    • lui_gough says:

      That’s correct. Each mumudvb instance will handle just *one* tuner, with *one multiplex* – so you will see channels only typically from one provider.

      The trick is to run a mumudvb instance for each of your tuners, and hand-author a playlist file (e.g. .m3u) which points to each of your mumudvb instances (running on separate ports, naturally). Each conf file for each mumudvb instance will need to use a different base port for this reason. Point your VLC at this playlist file to “get going” – alternatively, have it hosted on an HTTP server so other viewers (e.g. ProgDVB and XBMC Simple IPTV Client) can get to it as well!

      If you want to see the contents of the playlist files – it is in the article or you can inspect http://goughlui.com/tv.m3u noting that each channel has an #EXTM3U #EXTINF:0,channel name, followed by the actual URI. You will see I’ve run instances at 4002, 4007, 4009, 4010, 4028 and 4031 (not in the .m3u yet) which represent each local broadcaster (although the choice of port numbers was arbitrary).

      I hope this is enough information to get you going.

      – Gough

  2. Steve says:

    Nice article, thanks.

    I’m not sure that “Building a DVB-T TV Tuner Server with mumudvb” is the best title though.
    I think “Building a DVB IPTV streaming server” would have been better. It also matches the title that MuMuDVB uses on their website homepage.

    You said you don’t recommend amplifiers from Xiamen Seebest. Which amplifiers do you recommend?

    A picture of your system would have been very interesting to see.

    I guess you leave the system on 24×7. How much power does it use?

    Can you comment on the similarities and differences between MuMuDVB and MythTV. I think there is some overlap of features. MythTV, like MuMuDVB, can be configured with multiple TV tuners and can stream TV. MythTV can also function as a PVR/DVR and record TV shows for later use, which MuMuDVB does not do.

    When using MuMuDVB what solutions would you recommend for recording TV shows and for accessing a TV electronic program guide?

    • lui_gough says:

      It may not have been the best title, but it was mainly a side project that I decided to embark on mainly because of issues with lack of TV sockets in a rental property, but a good amount of Ethernet was already functioning.

      Xiamen Seebest amplifiers have caused me nothing but grief with non-standard F-connector threads and poor signal quality all round. Larger amplifiers seem to be made with pairs of sockets driven by one transistor set which seems to be problematic. At the moment, I’m using an Antsig UHF/Combo + VHF Distribution Amplifier (8-ports) with 6 ports used for tuners and two terminated with 75 ohm F-connector terminators. It is surge protected as well, and seems to put out a better signal. The next point of fragility seems the MCX connectors on the RTL-based tuners I’m using, although if you don’t physically move the tuners, it works just fine. It seems to be an older version of this unit: http://www.bunnings.com.au/antsig-8-way-indoor-distribution-amplifier-vhf-uhf_p4360394

      I haven’t put a picture up because I haven’t thought of taking one. At the moment, I’m a bit busy, but I might be able to share a picture in a few days. I do leave my system on 24/7 – it’s a AMD Sempron 145 based system with a single old 60Gb IDE Hard Drive. Power consumption of the whole system + USB Hub + Distribution Amplifier is about 46 watts mainly because the CPU is mostly idle. It’s a fair amount of electricity, although you can (and I have) run single tuners from Raspberry Pi boards (they’re a bit weak if you intend to have many many clients, and aren’t great for multiple tuners) and they would consume about 3W each, so I suppose you can achieve similar for about 25 watts when the amplifier is included.

      I don’t personally use MythTV, but I will note that VLC and dvblast are both also capable of streaming from TV tuners. VLC can also transcode, but it seems that its handling of multiple programs on a single transport stream is a little complicated. dvblast is quite similar in some regard but is more tailored for RTP/UDP/unicast/multicast, and is probably a better choice, but I wasn’t aware of it at the time I was playing with this. I mainly run this site to remind myself of the projects I have undertaken out of pure hobby interest, given it’s been so long ago, some information is bound to be outdated.

      The main idea for MuMuDVB is more for UDP multicast, however, because of home networking equipment constraints, results in flooding of all ports with broadcast traffic so instead I use the unicast beta feature instead.

      I don’t normally record TV shows, but I have been able to easily achieve this by scripting up a wget instance, or even by using Free Download Manager with the video URL and a defined start-end schedule time (and strict orders for one port, no resume operation). To watch TV, VLC is very capable, and can even record a program which is playing. You can access the program guide through the menus. Likewise, ProgDVB (even the free edition) is capable of tuning into the streams and parsing the embedded SDT data, although you will need to write and host a playlist file so that the IPTV plugin can find the channels. I have even used the IPTV plugin in XBMC and it seems to work as well, although if the network is congested the players start doing funny things.

      Hope this answers most of your questions – and of course, it’s always best to do some research and choose the solution that fits your needs best. Maybe you need to try some things before you come to your final answer – and with many open source/free solutions, all it costs is time. For me, I started with MuMuDVB and it worked well enough for me that I haven’t moved elsewhere.

      – Gough

      • nickandrew says:

        Interesting. I use MuMuDVB on a desktop server on the rare occasions I watch TV and it does a good job. I have 2 x Philips TDA10046H DVB-T dual tuners (older) and 1 x af9013 dual tuner (newer)

        Recently I tried tvheadend on the Raspberry Pi but it suffered from a few problems. Firstly the older tuners draw too much current. I have a USB voltage/current meter. Plugging in just one of them shutdown the port. Even using a powered hub I wasn’t able to get the older tuners to work on the Pi.

        The newer tuner works on the Pi (directly connected or through the powered hub) but it’ll work for hours and then cause the Pi to crash.

        I also tried tvheadend on the desktop server (which normally runs the two older tuners only) and it works, but output quality is noticeably lower than that of MuMuDVB. I don’t understand why; I would have expected them to be identical. As far as I know, both of them are decoding the Transport Stream.

        Although tvheadend has many impressive features (configuration, combining and sharing adapters, EPG) this quality difference is leading me toward using MuMuDVB and running simultaneous servers to multicast all channels. I can do that if I add the new tuner to the desktop server.

        I don’t have an amplifying splitter though and I’m starting to think about buying one, as the signal level on some channels is marginal and MuMuDVB does have trouble figuring out pids.

        • lui_gough says:

          Sounds like you have it sorted! The Raspberry Pi can be a bit fragile, and older tuners do consume a decent amount of power from the USB port which will cause problems for the Raspberry Pi unless you have modified it to remove the Polyfuse protection on the input. In general, MuMuDVB works fine with a Raspberry Pi provided you only use one tuner – the Ethernet port and the tuner share the same USB bus on the Raspberry Pi, and the CPU and USB buses will run out of breath if you have too many clients (more than about 4-5). Overclocking is virtually mandatory for the Raspberry Pi to achieve stable streaming, although overclock too much and you’re introducing a new source of instability.

          I haven’t tried tvheadend myself, so I cannot comment as to why there might be quality differences. Technically, a demuxer should be a demuxer … and the quality should be identical. If there’s transcoding going on, I think you’d notice it from checking the media type, bitrates and CPU usage.

          Thanks for your comment though!

          – Gough

  3. Steve says:

    I think dvblast supports multicast only, and not unicast (but it is not clear from the webpage). If so then dvblast is not usable without a switch supporting IGMP.

    My concerns with using MuMuDVB is that it needs 6 TV tuners to watch all channels. I know the USB tuners tend to get very hot, so having 6 may generate a lot of heat. But they are only small, so perhaps it is not too bad.

    I would prefer to have just 3 or 4 tuners that can be used to dynamically switch to whatever channels are requested – similar to the way the SiliconDust HD HomeRun operates.

    I’m currently using XBMC (OpenELEC version) for just one TV. It is OK for recording a single TV show, but I can’t get it to work for recording a TV series every week. I plan to test out and probably switch to MythTV. It has better TV recording support and it can stream video to other devices. Later I may look at MuMuDVB or a HD HomeRun if I find that MythTV can not do the live TV streaming.

    • lui_gough says:

      Yeah, part of the reason is because it’s going to tune the tuner to just one multiplex at a time (simple, no fuss autoconfiguration). You can get away with 5-tuners in Sydney if you don’t watch TVS. Maybe the other options work better for now, unless you’re inclined to develop some “logic” into how the tuners are to be switched based on which streams are being requested at any time. It would be possible but requires a global knowledge of all the services beforehand.

      – Gough

  4. Steve says:

    I used a RTL2832U TV tuner in an OpenELEC HTPC and it worked reasonably well. But it does get very hot, and sometimes the TV reception would have errors and the picture would break up.

    I bought four Microtune AF9135 USB tuners from ebay.
    http://www.ebay.com.au/itm/USB-2-0-DVB-T-Digital-TV-Receiver-HDTV-Tuner-Dongle-Stick-Antenna-IR-Remote-HP-/141510381180
    Linux detects them as ITE 9135(9006) / Afatech AF9033.
    They are cheap, do not have a radio, and unlike the RTL2832U TV tuner they do not get very hot.

    I think they would be ideal for a mumudvb IPTV server, or MythTV.
    I plan to setup MythTV to test them out.

  5. Athar Mian says:

    Hi Gough,

    Hi from Toronto ! Read your personal email instructions, so posting here.

    1. Any updates, especially with any comparisons with tvheadend that supposedly
    is a good plugin with Kodi?

    2. I am looking for a open source or cheap solution whereby I can stream tv
    channels over one directional broad cast ( no return channels) coax cable
    from an IPTV server after RF QAM modulation for digital channels.

    From iptv server I need the t.v. channels encrypted via conditional access
    such that a standard dvb-c set top box can decrypt those channels. Nagra
    and Iredeto like commercial solutions are expensive, so maybe something
    like Euro standard BISS, part of DVB standard can do the trick in software…

    Purpose is to stream free MOOCs ( massive online courses) in the developing
    world where internet access is still expensive, but coax cable t.v. is watched
    by everyone! Hence the hybrid solution. The scrambling creates a premium tier
    without ads for those who can pay a bit for educational programming. But of
    course no sophisticated encryption is necessary: who wants to steal such channels?!!

    Regards,
    Athar.

    • lui_gough says:

      Dear Athar,

      I haven’t had any time or need to follow up on IPTV serving as mumudvb has been serving us well enough at home for a while now, dealing solely in FTA. From some of my friends who have tried tvheadend, it is very awesome and a much more integrated solution for people who would prefer something more flashy with EPG functionality etc, but again, I have no time to test or inclination to change a system that works well enough. Maybe you can try it on your own and see, given that it’s all “free” and all you need is some spare hardware and time.

      The second issue you bring up is a much more complicated one. If you already have a DVB-C modulator with IP-based transport stream input, then things aren’t as difficult, but these are relatively expensive of course. In fact, commercial DVB-C modulators may also have BISS capability built in. If you don’t have access to this, then you’re at the mercy of software-defined radio solutions (e.g. BladeRF) with low RF output power (possibly requiring external linear-amplification) and software-based signal generation which is CPU-heavy and unreliable especially due to sample rate differences between the SDR and PC resulting in occasional timing/phase loss and glitches in the output. Already, DVB-T and DVB-S style modulation with SDRs has been achieved, although I’m not sure whether DVB-C has.

      In all cases, transport streams can be sent via UDP over IP assembled at a given bitrate by ffmpeg and has been seen commercially on DVB-S2 broadcasts in the past. To apply BISS is another relatively CPU-intensive operation, as it is hardware-optimized, but generalized CPUs are not particularly good at it resulting in bitrate limitations of ~20-30Mbit/s in practice. I don’t think ffmpeg can apply BISS, but VLC certainly can with its MPEG-TS output. As a result, you have to chain operations together and I’m not sure how well that would work at all. Maybe you can use VLC sourcing the stream over IP, and outputting a BISS-coded version over IP to localhost as MPEG-TS, and use ffmpeg to buffer the TS with null packets up to the required broadcast rate – although I’m not sure how ffmpeg might handle encrypted MPEG-TS input. Otherwise, it may be necessary to get VLC to receive the stream, pass it on to ffmpeg, then pass it back to VLC to add BISS, but then it might be possible that you won’t get the exact TS rate expected due to delays or overheads from BISS resulting in buffer overflows/underflows. Timing can be everything here.

      Of course, BISS key dissemination is a big issue, due to the static key encryption. It would render your efforts completely meaningless if the keys were to leak or be distributed, and there is no ability to manage/revoke permissions unlike commercial CA solutions. Furthermore, it is an “inconvenience” to end users as they will have to configure and manually provision their receivers for it as well.

      It’s a possibly complex undertaking, especially if you wish to get broadcast-grade output on the cheap. I can’t really give you any further advice, although, I would suggest that you don’t expect to be able to get a highly reliable DVB-C signal without an expensive dedicated standalone commercial modulator from the likes of Ericsson, etc.

      – Gough

      • Athar Mian says:

        Gough,

        Thanks much for your very detailed answer ! You tuly are knowledgeable 🙂

        Basically I don’t care very much about “good” or strong encryption since
        my target audience is better off subscribing to a pay TV service than trying
        to break encryption via CCAM which would require more expensive Internet
        access and set-up. BISS I used as example: any kind of reasonable scrambling
        would do instead of full Nagra like encryption. And the keys don’t have to circulate very
        frequently thus …so that is why I thought that such can be implemented in open
        source.

        I also believe that if you implement such a system in the Cloud like Google or AWS
        you might just have good enough resources to rent; Google has its own OBE, Open
        Broadcast Encoder, and Wowza Media Server also is a good tool. Maybe there are
        BladeRF like emulation tools too: Will have to check. But starting with a few SD channels
        with 20-30 Mbps should be good enough for now.

        Do you believe that transport being in one direction is a problem for STB
        decryption? What I read is that tsdecrypt is the protocol that actually receives the
        decryption keys from the key servers- Nagra, Irdeto, Conax, newcamd, OScam- via definition of IP address and ports.

        How might one define such without actually having an IP connection?

        Again, really appreciate your answers…

        Cheers,
        Athar.

        • lui_gough says:

          What you’re mentioning about encryption key distribution via IP is a “card sharing” system rather than a real CA system. Most real CA systems (e.g. Conax, Irdeto) are designed to operate one way only – i.e. the CA data is embedded into the output TS and is broadcast to all receivers to control key rotation and provisioning updates. Should the user call the subscription service to alter their subscription, the new CA data is broadcast from the headend to the receivers and they update accordingly.

          Unfortunately, such one-way CA systems with key rotation ability are rarely implemented correctly in open source, resulting in many complaints of cards failing to provision correctly after a period of time when not used with approved set top boxes for example.

          IP based cardsharing services typically circulate the CW (codeword) for decryption obtained from the CA system and basically pass this to a CSA decryptor (locally and remotely in the case of possibly illegal card sharing) to gain access to the stream. This is a “viewer” side system, but in reality, the commercial CA systems for legitimate subscribers look different because there is no need for the IP connections whatsoever. The CA data from the broadcast reaches the CAM/card, and that returns the necessary CW, and performs the descrambling all locally.

          Free and open equivalents do not exist to my knowledge. Again, I cannot really help you with this because my knowledge is limited – I don’t run my own broadcast, and I don’t provision CA systems for a living.

          – Gough

          • Athar Mian says:

            Gough,

            Right again on CA broadcast vs card sharing via IP. The latter schemes are circulating
            and really are meant for IPTV STBs or IP enabled card sharing nets. So hopefully I would
            be able to get a good deal out of Conax et al and multiplex their key broadcast within my MPTS
            MPEG stream to be QAM modulated locally for transport over coax to the client DVB-C
            STB whereby pay TV descrambling will occur.

            Thanks for clarifying…I haven’t seen any open source solution either yet, though we plan to deploy
            our own STBs after testing. Will keep looking with Conax as Plan B ! In theory a simple broadcast
            with own STBs deployed should be possible. But as Yogi Bera said: In theory, theory and
            practice are the same. In practise they are different.

            Have a good day…it’s midnight here 🙂

            Cheers,
            Athar.

  6. Alex says:

    Great information. This is the most basic and still understandable. My main question. To transcode in main server so it doesn’t use 10mb/s. Do you have a new set up? I would greatly appreciate. Thank you

    • lui_gough says:

      As a quality freak, I still don’t run any transcoding myself. It is possible, however, if you also invoke VLC on the server with the source pointed to a localhost address … however, I’m not sure how well such a solution might handle reception dropouts and that sort of thing. Whether the VLC process can run unattended in the long term is not known. Possibly ffmpeg could be used as well as an alternative. You will have to investigate.

      – Gough

  7. Tiago says:

    Hi, one quick question.
    Does anyone know that if i only use 1 DVT adapter to capture all the available channels the video resolution will be lower than if i set 1 board for each channel?
    Because i am receiving the channels at PAL (720:576) when in my country i should get HD

    • lui_gough says:

      No. The transport stream is digital – one adapter can capture an entire multiplex (transport stream) bit-perfectly from the air. The resolution is unaffected by how many tuners, but more what they send is what you see.

      Maybe you are not tuned to the best multiplex, or there are multiple multiplexes on the air (Sydney has 5 to serve 30-something channels). In this case, you might choose to tune to a better multiplex carrying high definition services or research which multiplexes are on the air and have one tuner dedicated to each multiplex (as I have done).

      – Gough

Error: Comment is Missing!