Software Filewall schließe ich von daher aus. Es kann eigentlich nur am Router oder am Provider liegen - und am Router find ich nix, was eine derart selektive Sperre verursachen könnte.

@vandalgrim41: Einen Media Receiver besitzt Du nicht und oder kannst Dir ihn aus dem Bekanntenkreis nicht ausleihen?

Damit die Telekom- Teamies Dir helfen können, trage bitte hier:

https://telekomhilft.telekom.de/t5/user/myprofilepage/tab/personal-profile%3Atelekom-custom-user-profile-userdata

Deine Kontaktdaten ein, auf die nur die Telekom Teamies Zugriff haben.

Gruß Ulrich

Wenn Du oben in der Menüleiste der Fritzbox (via PC Browser) noch Live TV stehen hast, weiß die Fritte auf alle Fälle das Du einen Magenta TV Anschluss noch hast @vandalgrim41 

Die Einstellungen aus einer ollen 3390 hätte ich allerdings nicht eingespielt.

Muss mich daran liegen, aber man kennt das ja mit dem Pferd und der Apotheke.

Ich würde einfach mal ein Werksreset durchführen und das Ganze manuell, neu einrichten.

Vielleicht hilft das ja?

Gruss VoPo 

Vielen Dank @Grinch, das klingt wieder alles sehr logisch und trotzdem versteh ich nur Bahnhof. Für mich sieht mein tcpdump ähnlich aus wie bei dir allerdings weiß ich ja auch nicht worauf ich da achten muss. Ich hab auch noch ein bisschen gegoogelt und den einen oder anderen gefundenen Tipp ausprobiert aber weiterhin immer nach 2m10s stoppt der Stream. Auch hier wieder, wenn ich den gleichen Sender auf vlc@windows spiele, bricht ffmpeg nicht ab.

Ich hatte vor einigen Monaten nach Anleitung in der c't wireguard eingerichtet um für mein Smartphone einen VPN -Proxy zu haben, wenn ich mich in fremde WLANs einbuche. iptables ist da aber eher unauffällig:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Einige Beiträge die ich über Google fand, lassen mich befürchten, dass es womöglich auch an dem Netzwerkchip in dem Minirechner, der als Server fungiert, liegen könnte. Kann das sein? Wie rausfinden?

ip addr sagt jedoch:

eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

Hier noch mein tcpdump, gibts da was auffälliges? Die Einträge der anderen Geräte im Netzwerk habe ich mit ... ausgeblendet.

# tcpdump -i eno1 -v igmp
20:36:42.790461 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 allow, 1 source(s)]
20:36:42.806323 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_ex, 0 source(s)]
20:36:42.942445 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_ex, 0 source(s)]
20:36:53.505637 IP (tos 0xc0, ttl 1, id 65199, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
...
20:36:57.880615 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 72, options (RA))
    fritz.box > igmp.mcast.net: igmp v3 report, 5 group record(s) [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.252 is_ex, 0 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr igmp.mcast.net is
20:36:58.858367 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 64, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 4 group record(s) [gaddr 232.0.20.35 is_ex, 0 source(s)] [gaddr 239.0.0.250 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.
...
20:37:53.506578 IP (tos 0xc0, ttl 1, id 9367, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
20:37:57.448512 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 72, options (RA))
    fritz.box > igmp.mcast.net: igmp v3 report, 5 group record(s) [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.252 is_ex, 0 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr igmp.mcast.net is
20:37:59.018449 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 64, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 4 group record(s) [gaddr 232.0.20.35 is_ex, 0 source(s)] [gaddr 239.0.0.250 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.
20:38:53.507028 IP (tos 0xc0, ttl 1, id 22401, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
20:38:55.306456 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 64, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 4 group record(s) [gaddr 232.0.20.35 is_ex, 0 source(s)] [gaddr 239.0.0.250 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.
...
20:39:01.304558 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 72, options (RA))
    fritz.box > igmp.mcast.net: igmp v3 report, 5 group record(s) [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.252 is_ex, 0 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr igmp.mcast.net is
20:39:08.250452 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_in, 0 source(s)]
20:39:08.810460 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_in, 0 source(s)]

vandalgrim41

Hier noch mein tcpdump, gibts da was auffälliges? Die Einträge der anderen Geräte im Netzwerk habe ich mit ... ausgeblendet.

# tcpdump -i eno1 -v igmp

### der erste Request ist gut, mit 1 source:

20:36:42.790461 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 44, options (RA)) meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 allow, 1 source(s)]

 

### aber danach kommen Requests ohne sources!

20:36:42.806323 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_ex, 0 source(s)]

20:36:42.942445 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 232.0.20.35 to_ex, 0 source(s)]

# hier kommt dann der IGMP Query

20:36:53.505637 IP (tos 0xc0, ttl 1, id 65199, offset 0, flags [DF], proto IGMP (2), length 36, options (RA)) fritz.box > all-systems.mcast.net: igmp query v3

...

### und hier will der Server plötzlich wieder 0 sources

20:36:58.858367 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 64, options (RA)) meinserver.fritz.box > igmp.mcast.net: igmp v3 report, 4 group record(s) [gaddr 232.0.20.35 is_ex, 0 source(s)] [gaddr 239.0.0.250 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)] [gaddr 224.0.0.

Ja, da ist in der Tat irgendwas seltsam. Hab es oben mal reinkommentiert. Irgendwie hat nur der erste Request eine SourceIP, die nachfolgenden nicht mehr und auch auf die nachfolgenden Queries wird wieder ohne spezifische Quelle geantwortet - was nicht funktioniert.

Jetzt ist die Frage.. warum geht die SourceIP nach ein paar ms plötzlich verloren? 

Ich war mal so frei und hab mir deinen ffmpeg Befehl von weiter vorne kopiert und wenn ich den benutze habe ich den gleichen Effekt.

Scheint ein Problem von ffmpeg zu sein 🤔

Das Interessante ist, gibt man eine nicht existierende Adresse an, bleibt die Source bestehen.

Ebenfalls interessant ist, dass das rtp modul offenbar gar nichts von der Source Adresse weiss:

[rtp @ 0x6884b80] [verbose] SDP:
v=0
c=IN IP4 232.0.20.35
m=application 10000 RTP/AVP 33

Es scheint auch nur bei rtp aufzutreten. Verwende ich udp:// passen die Joins. Und wenn man das Format eh auf mpegts erzwingt, scheint auch das Schreiben in die Datei zu funktionieren. Im Zweifel probiers einfach auch mal mit

ffmpeg -report -loglevel verbose -i udp://@232.0.20.35:10000?sources=87.141.215.251 -c copy -f mpegts out.ts

Das funktioniert zumindest auf meinem NAS auch. Im erstellten Logfile finde ich auch gar keine SDP. Keine Ahnung warum das rtp Modul da noch diesen Umweg geht.

Jetzt wärs natürlich mal interessant wie das bei @HabNeFritzbox  aussieht. Bei ihm auf dem NAS funktioniert es ja offenbar auch mit der rtp-Url. Welche ffmpeg Version ist da denn drauf? Gibt die mit verbose logging ein anderes SDP aus? 

Dieses Problem (Abbruch des Streams nach ca. 2 bis 3 Minuten) gabs doch auch mal bei iPads (iPhones?). 🤔

Ich weiß aber auch nicht mehr, obs am iPad oder an der Wiedergabe-App (VLC) lag 🤔