Tvheadend

HTSP is primarily for control of all functions like recording, the stream is just a "side functionality". Using it for server2server communication would not be ideal, and that's why DVB->IP should be used instead if you have a non-ip based source.

Flole Systems wrote:

HTSP is primarily for control of all functions like recording, the stream is just a "side functionality". Using it for server2server communication would not be ideal, and that's why DVB->IP should be used instead if you have a non-ip based source.

Yes, but it's not just about control of functions. With HTSP only the relevand PID's are streamed. For example, if user selects German audio track, server won't stream English, thus saving bandwith.

S2S with HTTP just unreliable. Now I'm using Sat>IP TCP mode.
Main problem is, when HTTP input loses connection, all subscriptions will be just dropped, instead of retrying the source.
Sat>IP over the internet using UDP results in garbaged picture, because of UDP packet loss over hops.
Only what it works with acceptable results now is Sat>IP TCP in a VPN tunnel. However it's unpractical in some cases.

https://tvheadend.org/issues/2762

Sat>IP also only streams the PIDs necessary. Essentially there is no real difference between using Sat>IP and HTSP, especially there is no advantage using HTSP as it would create additional overhead while not offering additional functionality or reliability.

Now I'm testing it with two tvhe (same build from unstable apt repo).

Looks stable now. Anyway it's a bit mess to add new servers over vpn (have to edit startup flags to put desc.xml).
Before I've used auto discovery but it's not always reliable. SatIP sources were disappearing and reappearing with that.
So for now, upnp off and adding them manually by XML and it doesnt go off and on.