Tvheadend

How exactly should tvheadend know which is the right IP and which is the wrong one? Would be great if you could clear that up.

When the destination multicast address and port are the same, it is expected to be the same service.
I would configure this on first come, first serve basis so the first packet received would select the source address and only this would be accepted from that moment on. In my case it doesn't matter which source is chosen.

I also tried specifying source address in playlist like this:

#EXTINF:-1,HDTV: ARD
rtp://194.160.9.6@233.10.47.94:1234
but I'm getting following error:

iptv: plist2.m3u - HDTV: ARD in SANET2 - cannot find ip address for interface (null) [e=Resource temporarily unavailable]

It's time to put udpixy on each interface with multicast.

saen acro wrote:

It's time to put udpixy on each interface with multicast.

I have a different workaround and it's time to improve tvheadend.

Can anyone think of a valid scenario where it's actually wanted to receive a single stream from multiple IPs/Sources? I think that would also cause quite some out of order packets so maybe we could indeed simply filter it and then just be done with it. This could also be a potential Denial-Of-Service issue if someone just sends random packets to the wide open UDP Port that is receiving the stream.

Actually one possible solution would be that during mux scan, the source IP would be detected and saved. But it may break services which often change source IP.

FFMpeg support multiple inputs as beckup input, when first fall switch to next.
Similar scenario exist in DVB inputs in TVH.

Flole Systems wrote:

I was just trying to figure out if it's indeed as simple as getting the IP from the first packet and "locking" on that.

Yes, this is exactly what I would preffer.

If there is a valid scenario where half of the stream comes from x and the other half comes from y that would obviously not work and we need this to be optional.

This doesn't seem to be probable because the latency synchronization would be impossible in most networks.

For failover the stream just needs to be restarted and it will lock on the IP of the backup source if that's the only one sending.

Fine for me.

Maybe full SSM implementation? SSM, so we have one multicast, and multiple sources, where one is main, another is backup..