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

[#1]

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

[#2 · Accepted solution]

---

@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? 

[#3]

Prinzipiell kann ich in der ffmpeg Liste auch udp statt rtp eintragen. Bin mir halt noch nicht so ganz im Klaren drüber, was das für andere Tools bedeutet. Die Streams sind technisch ja durchaus rtp und das scheint ffmpeg wohl auch zu erkennen, wenn man nur von udp spricht - denn sonst würde es nicht funktionieren und gäbe Bildstörungen, wenn ffmpeg die rtp header nicht entfernt, sondern als "Daten" betrachtet.

Warten wir mal noch @HabNeFritzbox Rückmeldung ab. Vielleicht kann er ja mal mit tvstreamrecord testen, ob da udp:// auch funktioniert. Dann würde ich auf udp:// umstellen, bis sich jemand anderes beschwert oder rtp:// auch funktioniert 😁

[#4]

@Grinch Der erste Versuch schlug fehl ("Please check your settings. Description: [Errno url error] unknown url type: 'udp' "), musste dem Tool erstmal sagen bei Protokolle, dass der auch udp verwenden darf/kann.

Dann klappte es auch mit udp://

Das Tool verwendet -y -loglevel fatal -acodec copy -vcodec copy, so wird kein Format erzwungen egal in welche Richtung und einfach 1:1 kopiert.

Wenn ich mal mit verbose schaue, dann scheint udp die bessere Wahl zu sein. Bei rtp steht input auf rtp und es kommt zu Fehler wie

[rtp @ 0x19c03e0] max delay reached. need to consume packet bitrate=7901.5kbits/s speed=1.17x
[rtp @ 0x19c03e0] RTP: missed 63 packets
[rtp @ 0x19c03e0] PES packet size mismatch
[rtp @ 0x19c03e0] max delay reached. need to consume packet bitrate=8071.0kbits/s speed=1.08x
[rtp @ 0x19c03e0] RTP: missed 98 packets
[rtp @ 0x19c03e0] PES packet size mismatch
[rtp @ 0x19c03e0] max delay reached. need to consume packet bitrate=8127.9kbits/s speed=1.05x
[rtp @ 0x19c03e0] RTP: missed 86 packets
[rtp @ 0x19c03e0] PES packet size mismatch

Bei upd steht beim Imput mpegts und kommt zu keinem der zitierten Fehler.

Wenn ich Aufnahmen selbst schaue, hatte ich bisher dort immer teils kleine Aussetzer bzw Pixelstörung, beim Test mit udp ist davon bisher nichts aufgetreten. Und dass bei nur 1-2 Minuten Aufnahmen im Test gerade.

Und entferne doch bitte die Nummerierung sowie SD bei den Namen in der Playlist. Die Senderlogos, Namen und auch EPG Datenbanken haben kein "SD", wenn nur Sender und ggf. zweites mal mit HD als Zusatz.

[#5]

Hm.. ich seh schon, ich muss das doch mal irgendwie konfigurierbar machen. Was ich  in den letzten 2 Tagen schon alles für Fragen zur Anpassung bekommen habe, man kann es sonst nicht allen Recht machen.

Aber gut, die FFMPEG Liste ist ja praktisch eh auf deinen Input hin entstanden, schauen wir mal ob das jetzt jemand anderem nicht passt

Ist jetzt also wie folgt:

- Kanalnummern habe ich entfernt

- Kanalname ist bei SD Kanälen der Name der EPG Position (Spalte 3 der Tabelle) und sonst der Name des Senders, wie er von der Telekom kommt (dort ist immer SD/HD/UHD enthalten).

Das sollte hoffentlich passen. Denn die Namen anpassen würde ich nur höchst ungern. Das ist ja gerade der Grund für die Datenbank gewesen, dass sie sich automatisch mit den Daten von web.magentatv.de befüllt und aktualisiert. Wenn ich da jetzt wieder drin rumbastle, hätte ich gleich bei der manuellen Variante wie bisher bleiben können 😅

[#6]

Wenn die Liste immer aus einer Quelle erzeugt wird, reicht es doch in der Ausgabe im PHP mit rexeg oder so entsprechend dass „SD“ zu entfernen samt Leerzeichen davor.

Kannst doch alles in einer PHP basteln, ggf. auch wie es angedacht hast mit Optionen, dann musst eh Ergebnisse manipulieren durch andere Sortierung, oder nur Hauptsender ohne 5 mal NDR und co. je nachdem was noch für Filter/Optionen anbietest.

Da kann man sich ja nochmal zusammensetzen wenn möchtest. Ist hier ja nicht direkt Thema.

Liste mit udp steht im Test also bisher nichts entgegen. Für Rest kann man ja noch Artikel schreiben mit Randinfos und so.