Feature #1097

Tvheadend on multiple servers

Added by Dave Chapman about 11 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



Firstly, it may help if I describe my current DVB setup. I have PCs located in Barcelona and London, each containing DVB-T tuners. Both sites also have DVB-S cards. In Spain I have LNBs pointing to Astra 28E and 19E and in the UK I have Astra 28E and Hotbird 13E.

In Spain, I have a 14Mbit/s download, 1Mbit/s upload ADSL connection, and in London I have a 76Mbits/s download, 18Mbits/s upload FTTC connection. This means I can stream live TV from the UK to Spain (including most HD), but I can't stream in the other direction in realtime.

What I would like to do is to install tvheadend in both locations and have a client (running on the Raspberry Pi) in each location. From the client's point of view, I would want to present a unified interface to both servers. Some features that I think would be possible to implement are:

1) Present a unified channel list for live viewing in the client. In my case, UK channels (DVB-T and Hotbird) will be available for live streaming to Spain, but not the other way around.

2) Present a unified list of available recordings. If recordings are located in Spain and the client is in the UK, then give the option to start a transfer to the UK.

3) Allow the UK client to schedule recordings in Spain, which are then transferred in non real-time to the UK.

4) Where services are available to both the UK and Spain (i.e. Astra 28E), perform redundant recordings in both locations in case of recording failure/error in one site.

(I am sure there are more things this kind of setup will make possible...)

Things are in fact a bit more complex than this, as I have two servers in each location... This gives the option of distributing recordings and live streaming across the servers within a single location (dependent on available tuners and disk space).

I haven't given much thought to the technicalities of all this yet, but have mentioned the idea in IRC and the idea of Tvheadend instances communicating between themselves using HTSP has been suggested.

I've opened this task in the hope that it will start a technical discussion on how we can implement this.



Updated by Djuri Baars about 11 years ago

I am in a comparable situation, luckily I have in both locations 100 mbit FTTH, so the streaming is not a problem.

I have been using the XBMC-PVR media center system which allows multiple TV backends like TVHeadend, MythTV, VDR, ...
Unfortunately this does not yet allow multiple servers of the same backend-type. if this would be implemented then we have a nice solution for our problem, at least for XBMC-PVR. Since it is open-source it could be easily adapted for some standalone solution if desired.

To keep TVHeadend lightweight I think front-ends are the most appropriate place to implement this kind of functionality.


Updated by Dave Chapman about 11 years ago


Yes, I've been thinking about this since I opened this issue, and am coming to the same conclusion - that most of this can be done by the client. Although when I discussed it in IRC, people seemed open to the idea of tvh instances communicating between themselves.

Your situation is easier, as your bandwidth means you can just treat local and remote servers the same. Something that may be better implemented inside tvh is the "remote recording" - where a recording is made on a remote server and then transferred slower than real time afterwards.

But this is related to another feature I want to see in tvh - importing of external recordings. If I do that, then I could script this transfer without changing anything inside tvh.

I'll see how things develop...


Updated by Viktor Fogelberg about 10 years ago

+1, bump. :)

A HTSP client in tvh would enable for some really sweet setups


Updated by Viktor Fogelberg about 10 years ago

A possible workaround would be to use vtuners.
but then the recordings wouldn't be managed between the servers at all and possibly a lot of unnecessary bandwidth would be used.


Updated by Adam Sutton over 9 years ago

  • Category changed from General to IPTV

You can sort of do this atm by using IPTV HTTP input, but I still think a much better HTSP hookup would be good.



Updated by danny skjodt over 9 years ago

Http input is way to bugged for that, the code locks up the tvheadend process sometimes when a http input is started.

Tvheadend also has all kinds of limits, for example it cant cope with auto switching source if one input dies, and you have 2 inputs mapped to that channel. Or even try to restart the http thread without the client having to stop start the channel, and if 2 clients is on the same channel whats the chance of that happening, none :)

wget + mbuffer + tsplay works quite good, used like this :

wget t1 -T3 -qO http://linktochannel | mbuffer -q | tsplay -stdin -buffer 256 -i

-t1 means only try once, -T3 means timeout if no data within 3 seconds, this way you can script it to have multiple sources and jump to another if no input on the first one.
mbuffer is a little buffer tool that prevents tsplay from halting wget.

The scripting part is pretty simple make a script that reads the tvheadend logfile in realtime and starts / stops channels on the multicast addresses you use within tvheadend.

Tvheadend and these simple tools scales pretty good, on decent i7 hardware you can easy be running 100 sd channels, or about 500 mbit mpegts processing.

Also available in: Atom PDF