Direkte URLs zum Streamen von MagentaTV Basis-Sendern funktionieren nicht mehr

vandalgrim41 · ‎22.12.2019

Ich habe den Tarif „Magenta Zuhause L mit TV“ aber ohne MediaReceiver und schaute bisher die unverschlüsselten Sender des Basispakets über Plex mit dem Wrapper xTeVe. Seit ein paar Tagen funktioniert das leider nicht mehr.

Auch auf dem Windows-PC kann ich mit dem VLC nicht mehr die Streams abrufen. Ich habe die Ursache noch nicht gefunden, wollte aber mal nachhören, ob das bei euch generell noch funktioniert. Dann läge es hier entweder am Vertrag oder an der neuen Fritz!Box, wobei ich da schon 3x alle Einstellungen durchgesehen habe.

Ich habe jeweils beide Versionen der URLs probiert, mit und ohne Proxyteil, bzw für Entertain/Magenta. Zum Beipspiel für "Das Erste HD";

rtp://87.141.215.251@232.0.20.35:10000

rtp://@239.35.10.1:10000

Grinch · ‎10.01.2020

@vandalgrim41 schrieb:
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?

Lösung in ursprünglichem Beitrag anzeigen

vandalgrim41 · ‎23.12.2019

Vielen Dank für die vielen Tipps zu VLC unter Windows. Aber Windows war ja nur die Gegenprobe. Der Stream soll vom Linuxserver empfangen werden und dann via Plex-MediaServer an die Plex-App auf dem AppleTV restreamt werden, was bis vor gut eine Woche ja auch funktionierte.

Aber jetzt wirds merkwürdig: Seit heute kann ich mit vlc@windows tatsächlich wieder alle rtp streamen, ohne dass ich bewusst was geändert hätte. Auf Linux jedoch weiterhin Fehlanzeige.

Hier funktioniert nur 3sat-HD, der in meiner m3u der einzige (weil vergessene) Sender ohne Proxyanteil in der URL ist (Entertain): rtp://@239.35.10.47:10000

Das Erste HD läuft auf Windows aber nicht auf Linux mit der MagentaURL rtp://87.141.215.251@232.0.20.35:10000

Ich hatte sogar versucht hier eine Statische Route einzurichten "sudo ip route add 87.0.0.0/8 via 192.168.xxx.1 dev eno1", wobei das eh die default route ist.

Weiters habe ich auf dem AppleTV noch die App "GSE Smart IPTV" um die Streams direkt mit dem AppleTV zu streamen. Auch das hat mal funktioniert, doch auch hier nur noch 3sat-HD und die Streams die nicht von Magenta stammen.

kurz59 · ‎23.12.2019

@vandalgrim41

beim nicht Win/VLC System bin ich raus.

vandalgrim41 · ‎29.12.2019

Vielen Dank nochmal für die ganzen Tipps. Ich bin erst jetzt dazu gekommen die mal auszutesten.

Werksreset an der neuen FB7590 und nur den Assistenten für die Ersteinrichtung laufen lassen, gleicher Fehler. Zuvor gemachtes Backup zurückgespielt, Fehler erwartungsgemäß noch da.

FB7590 getrennt und alte FB3390 wieder dran gegängt. Alle Streams über Linux/AppleTV wieder da. Es liegt also definitiv an der neuen FB7590.

Ich hab an der FB7590 sogar mal KURZ die ganzen Haken bei den Globalen Filtern entfernt und gemäß AVM FAQ den UDP-Port 10000 auf den Linuxserver weitergeleitet. Alles ohne Erfolg.

Ich hab erst mal ein Ticket bei AVM angelegt. Mal sehen, was die dazu meinen.

HabNeFritzbox · ‎29.12.2019

Routen für Multicast kannst eh vergessen. Auch Portweiterleitung ist Quatsch, du betreibst ja keinen Server, sondern willst Daten empfangen.

Hier könnte eher dein Switch oder so ein Problem sein. Oder Firewall am deinem Server selbst.

VLC akzeptiert z.B. rtp://87.141.215.251@232.0.20.35:10000 jedoch nicht ffmpeg. Wenn also den Stream über ffmpeg verarbeitest verwende rtp://@232.0.20.35:10000?sources=87.141.215.251

Habe dem @Grinch dazu auch schon Infos geschickt für ne Anpassung seiner tollen Sammlung.

vandalgrim41 · ‎06.01.2020

@HabNeFritzbox Ich bilde mir ein, als ich das gleich nach deinem Tipp getestet habe, dass es nicht funktioniert hat. Auf Grund eines neu entdeckten Phänomens habe ich es gerade nochmal auf der SSH Konsole meines Lunux-Servers versucht und jetzt klappt es mit diesem Befehl:

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

Um aber auf das neue Phänomen zurück zu kommen... Wenn ich auf dem LinuxServer obigen Befehl mit dem ursprunglichen Linkformat aufrufe (rtp://87.141.215.251@232.0.20.35:10000) passiert zunächst mal nichts. ffmpeg wartet unendlich auf Daten. Wenn ich nun jetzt parallel auf dem Windows-PC mit VLC den gleichen Stream starte, fängt in der Sekunde auch ffmpeg auf dem Linux-PC an, den Stream zu empfangen und zu speichern. Sobald ich den Stream auf dem Windows-Rechner anhalte, bekommt auch ffmpeg keine Daten mehr. Ich werde dann wohl am Wochenende noch mal bischen testen müssen bzw. die m3u auf dein Format ändern.

Herzlichen Dank für den Tipp

kurz59 · ‎06.01.2020

@vandalgrim41

schau mal da

https://iptv.blog/2020/01/in-eigener-sache-iptv-blog-datenbank/

viper.de · ‎06.01.2020

@vandalgrim41 schrieb:
Wenn ich auf dem LinuxServer obigen Befehl mit dem ursprunglichen Linkformat aufrufe (rtp://87.141.215.251@232.0.20.35:10000) passiert zunächst mal nichts. ffmpeg wartet unendlich auf Daten. Wenn ich nun jetzt parallel auf dem Windows-PC mit VLC den gleichen Stream starte, fängt in der Sekunde auch ffmpeg auf dem Linux-PC an, den Stream zu empfangen und zu speichern. Sobald ich den Stream auf dem Windows-Rechner anhalte, bekommt auch ffmpeg keine Daten mehr.

Dann hat Dein Linux Server ein IGMP Problem, der vlc abonniert den Stream und wenn er beendet wird auch die Gruppenmitgliedschaft beendet und da offensichtlich der Linux Server keiner Gruppe beigetreten ist wird der Stream auch nicht mehr durchgestellt.

HabNeFritzbox · ‎06.01.2020

Wie ich auch dem @Grinch mitgeteilt habe nutzt ffmpeg keine m3u, ist eher für Tools wie tvstreamrecord

http://pavion.github.io/tvstreamrecord/ wo so Sender importieren kannst.

Mal schauen ob er Namen noch anpasst, da im Tool Sender mit SD im Namen nicht findet für die EPG Datenbank.

Tool auf dem NAS setzt dann um z.B.

['/volume1/@appstore/VideoStation/bin/ffmpeg', u'-i', 'rtp://@232.0.20.35:10000?sources=87.141.215.251', u'-y', u'-t', u'3538', u'-loglevel', u'fatal', u'-acodec', u'copy', u'-vcodec', u'copy', u'/volume1/TV/2020-01-06_Das Erste HD_123.ts']

Stefan · ‎06.01.2020

@viper.de schrieb:

@vandalgrim41 schrieb:

Wenn ich nun jetzt parallel auf dem Windows-PC mit VLC den gleichen Stream starte, fängt in der Sekunde auch ffmpeg auf dem Linux-PC an, den Stream zu empfangen und zu speichern.
Sobald ich den Stream auf dem Windows-Rechner anhalte, bekommt auch ffmpeg keine Daten mehr.

Dann hat Dein Linux Server ein IGMP Problem, der vlc abonniert den Stream und wenn er beendet wird auch die Gruppenmitgliedschaft beendet und da offensichtlich der Linux Server keiner Gruppe beigetreten ist wird der Stream auch nicht mehr durchgestellt.

Mehr noch, offensichtlich hängt da ein nicht IGMP fähiger Switch dazwischen. Selbst wenn ein anderes Gerät den Stream abonniert, dann

dürfte bei intaktem Netzwerk der Linux Rechner den Multicaststream gar nicht zu sehen bekommen.

vandalgrim41 · ‎06.01.2020

@HabNeFritzbox Nun m3u ist ja nur die Playlist. Wenn da dann die Links aus der neuen Datenbank vom iptv-blog im ffmpeg-Format drin stehen sollte es passen. ffmpeg hatte ich ja nur zum Testen benutzt. Die Playlist selbst setzt ja xTeVe um und stellt dann dem Plex media Server eine virtuelle TV-Karte zur Verfügung. xTeVe greift dann den Stream via ffmpeg ab und und restreamt das zu Plex.

@Stefan Der einzige Unterschied war ja die neue Fritzbox. Mit der alten gings und der neuen nicht, bei gleicher Config. Den Linuxsserver hatte ich grad zum Testen auch direkt an die FB angeschlossen. Auch hier klappte es mit der @-URL nicht. Es muss die mit dem sources-Parameter sein.

Stefan · ‎06.01.2020

Magenta TV erfordert IGMPv3 mit SSM das ist schon richtig.

Mir ging es aber darum, dass das Linux plötzlich anfängt zu spielen, wenn ein Windows Rechner den Multicast Stream anfordert.

das darf nicht sein.In einem korrekt konfiguriertem Netzwerk muss jedes Endgerät ein
IGMP subscribe senden, damit der Switch den resultierenden Stream an diesem Port überhaupt ausgibt.

Offensichtlich schickt der Linux rechner diesen subscribe nicht, denn er beginnt erst mal nicht zu spielen.

Wenn dann Windows den subscribe schickt, dann darf nur der Windowsrechner die Multicastpacket vom Switch geschickt bekommen.

Offensichtlich schickt der Switch aber an alle Ports. Das führt in grösseren Netzwerken zum Totalausfall, da das Netz oder das Endgerät überlastet wird. Stell dir ein Gerät vor, welches nur 22mbit max über WLAN Empfangen kann, nun schauen zwei andere Rechner je einen HD stream mit je 11mbit/s. Das Gerät am Wlan bekommt diese mit voller Breitseite geschickt, ohne dass es diese Streams wiedergibt. hat aber selbst keine Chance mehr eigene Daten über die überlastete Stecke zu schicken. Das ist einfach Mist. Da muss ein Fehler im System sein.

Umgekehrt darf der Stream erst stehenbleiben, wenn der letzte Subscriber ein IGMP leave schickt

viper.de · ‎06.01.2020

Bis auf die WLAN Geschichte ok, tatsächlich ist es so, dass wlan Controller bei Multicasts auf die Basisdatenrate zurück schalten, das ist dann eher die Hälfte von 22MBit/s, deswegen gibt es die sogenannte IPTV Optimierung, die nichts anderes ist als aus dem Multicast einen Unicast zu machen. Dazu muss der WLAN Controller natürlich auch die MAC ID ersnoopen können.

Stefan · ‎06.01.2020

das Beispiel mit WLAN war auch eher der einfachheit halber gedacht, das es mir zu komplex war ein Beispiel zu konstruieren das von den Datenraten realistisch ist. meist geben die billig Switch einfach vorher auf, wenn sie nicht schnell genug switchen können

viper.de · ‎07.01.2020

Ist ja in diesem Kontext auch müßig darüber zu diskutieren, geht ja hier darum dass eine Applikation scheinbar die Streams gar nicht anfordert, an der Fritzbox wird es m.E. nicht liegen, die macht ja mit vlc Alles richtig, ich tippe immer noch auf nicht oder nicht korrektes IGMP eventuell auch noch im Zusammenhang mit Plattformwechsel.

Grinch · ‎07.01.2020

@vandalgrim41 schrieb:
Um aber auf das neue Phänomen zurück zu kommen... Wenn ich auf dem LinuxServer obigen Befehl mit dem ursprunglichen Linkformat aufrufe (rtp://87.141.215.251@232.0.20.35:10000) passiert zunächst mal nichts. ffmpeg wartet unendlich auf Daten. Wenn ich nun jetzt parallel auf dem Windows-PC mit VLC den gleichen Stream starte, fängt in der Sekunde auch ffmpeg auf dem Linux-PC an, den Stream zu empfangen und zu speichern. Sobald ich den Stream auf dem Windows-Rechner anhalte, bekommt auch ffmpeg keine Daten mehr. Ich werde dann wohl am Wochenende noch mal bischen testen müssen bzw. die m3u auf dein Format ändern.

Ich glaube das ist relativ leicht erklärbar.

Wenn du FFMPEG mit dem VLC Format fütterst, dann fällt die Source Option weg, da FFMPEG sie nicht erkennt. Sprich der Linux Server schickt einen IGMP Request ohne SSM.

Das kann, muss aber nicht funktionieren. Ich vermute mal die alte FB schickt den Request einfach trotzdem ins Netz weiter und das Netz ist so nett und leitet den Multicast auch ohne SSM weiter.

Hält man sich streng an die RFC, so ist die verwendete Multicast-Adresse aber für SSM reserviert, d.h. Geräte, die sich streng nach Standard verhalten, verwerfen Requests in diesem Adressbreich ohne SSM Option (deshalb ist es auch Glückssache ob die neuen Streams ohne SSM empfangbar sind). Schätzungsweise ist die 7590 da einfach strenger in der Auslegung als die 3390.

Dass es dann funktioniert, wenn du am Windows PC den gleichen Stream abrufst liegt vermutlich dann daran, dass der Windows PC die SSM Option mitschickt, die 7590 den Request damit ins Netz durchstellt und den Stream empfängt und ans LAN weiterleitet. Und damit kommt dann auch der Linux PC in den Genuss. Denn die Ziel-Multicast-Adresse hat der Linux PC ja auch ohne Einschränkung angefordert.

@HabNeFritzbox schrieb:
Wie ich auch dem @Grinch mitgeteilt habe nutzt ffmpeg keine m3u, ist eher für Tools wie tvstreamrecord
http://pavion.github.io/tvstreamrecord/ wo so Sender importieren kannst.

@vandalgrim41 schrieb:
xTeVe greift dann den Stream via ffmpeg ab und und restreamt das zu Plex.

Und genau deshalb heisst die Playlist bei mir eben "FFMPEG" und nicht "tvstreamrecord/xTeVe/sonstige, die ffmpeg im Hintergrund verwenden"

In welchen Tools ihr meine Playlists verwendet ist eure Sache.. die "Standard"-M3U wird zum Beispiel großteils in TVHeadend eingesetzt.

Mal schauen, vielleicht mach ich irgendwann mal eine "Toolauswahl" mit rein, die verknüpft, welches Tool mit welcher Playlist und welchem Format klarkommt. Bis dahin muss das jeder selbst rausfinden, bzw. im Tool seiner Wahl nachlesen welches Format das richtige ist. Sonst wird die Auswahl in der Listen einfach endlos und unübersichtlich.

vandalgrim41 · ‎09.01.2020

@HabNeFritzbox Nochmals danke für den Tip mit dem Link für ffmpeg. Jetzt habe ich jedoch ein neues Problem. Der Stream bleibt nach ziemlich exakt 131 Sekunden stehen und ffmpeg bricht mit "Connection timed out" ab. Im Log find ich dazu auch keinen Hinweis. Der neue Link funktioniert allerdings ohne Abbruch in der AppleTV-App "GSE IPTV Pro", die mit dem VLC-Format auch nicht zurecht kam.

Es liegt also auch hier an ffmpeg. Ich hab schon etliche Parameter durch, doch der richtige war nicht dabei. Jemand eine Idee?

Grinch · ‎09.01.2020

Klingt nach Firewall 🤔

Hast du da irgendwas konfiguriert? iptables oder so?

Solange ffmpeg läuft (und davon gehe ich mal aus, dass es da auch noch nach 131 Sekunden tut), möchte es die Multicast-Gruppe haben. Allerdings schickt der Kernel nur zum Beginn einen IGMP Request raus. Danach muss er aber auf die regelmäßigen Anfragen der Fritzbox antworten, sonst stellt die das Streaming wieder ein.

Dazu schickt die FB regelmäßig einen IGMP Query raus. Wenn der beim Server/Kernel nicht ankommt, dann antwortet er nicht und nach einer gewissen Zeit geht die FB davon aus, der Server ist tot und klemmt die Multicast-Gruppe wieder ab.

Im Zweifel auf dem Server mal tcpdump laufen lassen und nach den IGMP Paketen suchen.

kurz59 · ‎09.01.2020

Übrigens, die alten Entertain-Streams wurden jetzt abgeschaltet:

https://iptv.blog/2020/01/das-spiel-ist-aus-entertain-plattform-abgeschaltet/

Mächschen · ‎09.01.2020

@kurz59 schrieb:
Übrigens, die alten Entertain-Streams wurden jetzt abgeschaltet:
https://iptv.blog/2020/01/das-spiel-ist-aus-entertain-plattform-abgeschaltet/

Diskussion dazu bitte hier

https://telekomhilft.telekom.de/t5/Fernsehen/FYI-alte-Entertain-Plattform-ist-abgeschalten/m-p/43473...

Grinch · ‎09.01.2020

Zum Thema tcpdump, so sieht das im gesunden Zustand aus:

# tcpdump -i eth0 -v igmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
### Start: IGMP Join
18:21:56.827701 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.10.35 allow, 1 source(s)] [gaddr 232.0.10.35 to_in, 1 source(s)]

### regelmäßiger IGMP Query von der FB an alle
18:22:10.021704 IP (tos 0xc0, ttl 1, id 50113, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
### Antwort vom Server
18:22:11.983454 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]
### ggf. noch weitere Antworten von anderen Rechnern im Netz und andere Gruppen

### und dann dreht sich das im Kreis im Minutentakt
18:23:10.022433 IP (tos 0xc0, ttl 1, id 55524, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:23:17.387212 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

18:24:10.023816 IP (tos 0xc0, ttl 1, id 56711, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:24:10.459478 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

18:25:10.027621 IP (tos 0xc0, ttl 1, id 59829, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:25:11.975507 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

Das ist jetzt von einer FB7490. Aber ich schätze mal die 7590 macht das nicht groß anders. Wenn nach 130 Sekunden Schluss ist, hat sie vermutlich 2x keine Antwort erhalten und stellt dann den Stream ein.

Das kündigt sie so übrigens auch an, wenn man sich den IGMP Query anschaut:

QRV ist der Querier Robustness Variable, also wie oft sie frägt, bevor sie einstellt. In diesem Fall 2x und jeder Client hat 10 Sekunden Zeit zu antworten. Aus dem Intervall von 60 Sekunden ergibt sich damit recht genau die 130 Sekunden, die du beobachtest.

vandalgrim41 · ‎10.01.2020

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)]

Grinch · ‎10.01.2020

@vandalgrim41 schrieb:
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?

kurz59 · ‎10.01.2020

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 🤔

vandalgrim41 · ‎10.01.2020

@Grinch SUUUPER! Damit funktioniert es endlich!

Das Problem war also eine unglückliche Kombination verschiedener Probleme. ffmpeg verarbeitet rtp-Links offenbar nicht korrekt oder dieses Protokoll ist generell eher ungeeignet, was aber andere Programme nicht zu stören scheint. Und die alte Fritzbox verhielt sich weniger restriktiv und/oder beherrscht noch kein IGMPv3 und ließ ffmpeg gewähren obwohl kein regelgerechter Join/Subscribe (oder wie auch immer) zustande kam. Dadurch entstand der Verdacht, dass die neue Fritzbox das Problem war.

Das bedeutet natürlich, dass du womöglich in deiner Datenbank den ffmpeg-Teil auch auf udp://@ umstellen solltest oder beide Versionen anbietest. Ich vermute mal, dass die Listen eh dynamisch zusammengebaut werden, oder? Für mich hab ich das mit Suchen+Ersetzen selbst angepasst.

@Alle: Ihr wart super! Vielen Dank für die vielen Anregungen, die mich alle ein Stück weitergebracht haben, auch wenn es nur um die Mehrung von Hintergrundwissen ging. Ich hab einiges gelernt. Ich wünsche euch allen ein schönes, aufregendes TV-Jahr.

Stefan · ‎10.01.2020

wenn die alte Fritzbox kein IGMPv3 konnte, dann wäre nie auch nur ein Bild bei dir angekommen.

RTP ist eher nicht ungeeignet - faktisch nutzen es jeden Tag alleine in Deutschland 80 Millionen Menschen regelmässig.

Mansche mehr als 100 Mal am Tag. Über RTP werden die Sprachdaten beim Telefonieren übertragen

Direkte URLs zum Streamen von MagentaTV Basis-Sendern funktionieren nicht mehr

Social Media