Bug #5866
open
Multicast from multiple sources
Added by Daniel Kucera about 5 years ago.
Updated over 2 years ago.
Found in version:
4.3-1857~g221c29b
Description
Some networks may provide two sources for the same multicast address, see here:
```
21:41:26.577351 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577930 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577960 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.577975 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.578745 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579667 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579702 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.579708 IP 147.213.198.54.48724 > 233.10.47.97.1234: UDP, length 1328
21:41:26.580487 IP 194.160.9.5.48724 > 233.10.47.97.1234: UDP, length 1328
```
This currently results in continuity counter errors and inability to watch the channel:
```
Mar 31 21:33:15 speedy tvheadend31043: TS: ...: H264 #256 Continuity counter error (total 88744)
Mar 31 21:33:15 speedy tvheadend[31043]: TS: ...: MPEG2AUDIO #257 Continuity counter error (total 7560)
Mar 31 21:33:15 speedy tvheadend31043: TS: ...: MPEG2AUDIO #258 Continuity counter error (total 7565)
Mar 31 21:33:16 speedy tvheadend[31043]: TS: ...: TELETEXT #400 Continuity counter error (total 11127)
```
I'd like tvheadend to correctly distinguish this and receive data only from one source and filter out the other ones.
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.
- Status changed from New to Accepted
- Target version set to 4.4
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. 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. 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.
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..
- Target version changed from 4.4 to 4.6
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by