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!
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.
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 …
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.
Unfortunately, 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).
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.
In the end, my system looks like this:
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.
You will need to do this for each multiplex/tuner you want to serve.
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.
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.
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.
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.
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.
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.