Unverschlüsselte Multicast-Kanäle mit anderen Geräten empfangen (Wiki)

Ich denke es wird langsam Zeit eine Übersicht der möglichen alternativen Empfangswege von MagentaTV zu erstellen.

Da ich selbst nicht alles ausprobieren kann, ist das hier als Wiki ausgelegt und jeder ist eingeladen sich zu beteiligen, Beiträge zu ergänzen oder zu korrigieren.

Datenquelle

Grundsätzlich stehen die unverschlüsselt als Multicast zu empfangenden Sender in der Multicast-Adressliste zur Verfügung.

Dort findet ihr bereits fertige Playlist in gängigen Formaten. Welches Format für welches Programm benutzt werden kann müsst ihr im Zweifel ausprobieren oder den Hersteller fragen. In den nachfolgenden Abschnitten sind einige Beispiele, die ihr idealerweise direkt übernehmen könnt.

Empfangsgeräte mit Multicast-SSM-Support

Mit der Abschaltung der alten Entertain Streams ist SSM zwingend zum Empfang der Sender erforderlich. Neben dem Endgerät muss auch euer Heimnetz mit IGMPv3 arbeiten und euer Router einen IGMP-Proxy besitzen, der die IGMP Requests aus dem Heimnetz ins Telekom-Netz weiterleitet.

Für letzteres empfiehlt sich ein Gerät, das offiziell MagentaTV unterstützt. Eine Liste der von der Telekom vertriebenen Geräte findet ihr hier: https://www.telekom.de/hilfe/festnetz-internet-tv/magentatv/installation/geeignete-speedport-router

VLC

Die wohl bekannteste Variante die Sender abseits eines Media Receivers zu empfangen ist der VLC. Diese Softwarelösung ist kostenlos, läuft auf vielen Geräten und ist daher gut dazu geeignet bei Problemen die “Gegenprobe” zu machen.

Der VLC kommt mit fast allen Playlist-Formaten zurecht. Empfohlen ist derzeit die Playlist im XSPF-Format, da diese auch Senderlogos enthält. Ansonsten gibt es aber keine Unterschiede zu den anderen Playlists.

Wenn ihr das Protokoll rtp:// mit dem VLC verknüpft, könnt ihr auch die in der Liste angegebenen Links klicken. Bei VLC für Android sollte das von Haus aus funktionieren. Bei anderen Betriebssystemen müsst ihr diese Verknüpfung ggf. selbst vornehmen. Unter Windows könnt ihr dazu z.B. diese Registry Datei herunterladen, mit einem Texteditor eurer Wahl den Pfad zu VLC anpassen und in eure Registry übernehmen.

dvbviewer

dvbviewer ist kostenpflichtig, bietet jedoch weitaus mehr Komfort, als es bspw. der VLC bieten kann. Neben dem Abspielen der aktuellen Sender beinhaltet dvbviewer jede Menge weiterer Funktionen wie Aufnahmen, Timeshift, EPG, ein TV-taugliches Interface, Fernsteuerung etc.

Für den dvbviewer nehmt ihr am besten die fertige Kanalliste und importiert diese mit dem Kanallisten-Editor in dvbviewer.

Die angebotene Transponderliste ist für das in dvbviewer enthaltene TransEdit. Dort könnt ihr die Transponder importieren und scannen, analysieren, editieren.

TVHeadend

TVHeadend ist eine Software, die einerseits als Proxy für den Live-Stream dienen kann, andererseits aber auch Sendungen aufnehmen kann. Zu den weiteren Funktionen zählt die Möglichkeit EPG Daten zu verarbeiten. Im Prinzip wie der Name andeutet ein eigenes kleines Headend für Zuhause.

SSM ist für TVHeadend auch noch relativ neu und funktioniert nach eigener Erfahrung erst ab TVHeadend 4.3. Solltet ihr also z.B. auf die fertigen Debian/Ubuntu Pakete zurückgreifen wollen, so müsst ihr derzeit dafür den “unstable” Branch wählen.

Für TVHeadend findet eine eigene M3U in der Datenbank, da noch weitere Daten, wie die Kanalposition und das Kanallogo extra mitgegeben werden können. Prinzipiell sollte aber auch die “normale” M3U funktionieren, wenn ihr diese Daten sowieso selbst anpassen wollt.

Da es verschiedene EPG Anbieter gibt, fehlt die EPG ID (die sich je nach Quelle leider unterscheidet) noch in der M3U. Das ist für eine zukünftiges Update allerdings in Planung. Bis dahin müsst ihr die Kanäle selbst verknüpfen.

Netzwerk anlegen

Als ersten Schritt müsst ihr ein neues Netzwerk in TVHeadend anlegen. Klickt euch dazu durch zu Configuration/DVBInputs/Networks/Add und wählt das IPTV Automatic Network.


Im erscheinenden Dialog braucht tragt ihr neben einem Namen eurer Wahl die URL der M3U ein und entfernt den Haken bei “scan after creation” (denn mit den Standardeinstellungen wird das sowieso nicht funktionieren) und setzt den Haken bei “Enabled”. Wenn ihr wollt, könnt ihr hier je nach verfügbarer Bandbreite auch die Gesamtbandbreite oder die Anzahl gleichzeitiger Streams begrenzen. Dann klickt ihr am Ende der Seite auf “Create”.

Muxes anpassen und Services scannen

Im nächsten Schritt müsst ihr die vom Netzwerk angelegten Muxe noch anpassen. Dazu klickt ihr zunächst auf das Tab “Muxes”, ändert unten rechts die Einträge pro Seite auf “All” und wählt dann alle Einträge aus (1. Eintrag anklicken, Strg + A drücken), und klickt auf Edit. Folgende Einstellungen solltet ihr im Dialog anpassen

  • EPG Scan: Ich würde hier auf “Disable” stellen, ihr könnt es aber auch aktiviert lassen. Der Effekt ist, dass bei aktiviertem EPG Scan TVHeadend regelmäßig alle Kanäle abfrägt und nach EPG Daten scanned. Der Nachteil: das belegt natürlich Bandbreite auf eurem Anschluss, die ihr vielleicht anderweitig nutzen wollt. Ausserdem enthalten die Streams lediglich die aktuell laufende und die nachfolgende Sendung. Sonderlich wertvoll ist die Option also so oder nicht. Insbesondere, wenn ihr im weiteren Verlauf einen EPG Anbieter einrichtet, der für Tage im Voraus Daten liefert. Solltet ihr das nicht tun wollen oder wollt hier immer aktuelle Daten zur gerade laufenden Sendung, könnt ihr es natürlich aktiv lassen.
  • Scan Status: Setzt den Wert auf “PEND” um im Anschluss direkt den Scan zu starten
  • Interface: die wichtigste Einstellung. Ohne ein gewähltes Netzwerkinterface funktioniert der Scan nicht. Wählt hier also das Netzwerkinterface aus über den der Multicast empfangen werden kann.


Bestätigt dann die Einstellungen mit “Save” am Ende der Seite.
Nach und nach sollten der Scan Status auf IDLE und der Scan result auf “OK” wechseln.

Service Mapping

Anschließend müsst ihr aus den Services Kanäle machen. Dazu klickt ihr auf das “Services” Tab und wählt “Map services”, “Map all services”


Hier könnt ihr eigentlich alle Haken entfernen, verschlüsselte Kanäle sind nicht in der Playlist, ein mergen funktioniert mit der Playlist nicht und ist meiner Meinung nach auch nicht sinnvoll. Es wäre zwar möglich die SD Kanäle ohne SD-Endung zu benennen und dann TVHeadend die HD Endung entfernen zu lassen und dann gleichnamige Kanäle zusammen zu fügen, allerdings ist es dann eher Glückssache, ob er resultierende Kanal in SD oder HD Qualität ist.
Die type-based tags funktionieren ebenfalls nicht richtig, da bei MagentaTV auch die SD Kanäle in H264 ausgestrahlt werden und TVHeadend diese dann als HDTV tagged.
Klickt abschließend auf “Map services”.

Damit sollte das Grundsetup abgeschlossen sein und ihr müsstet mit einem Client für TVHeadend die Kanäle sehen.
Für einen Schnelltest am PC bietet sich die Chrome App Movian an (in das Suchfeld die Adresse htsp://ServerIP eintragen). Ein anderer beliebter Client wäre Kodi.

EPG

Wie schon angedeutet, könnt ihr externe EPG Quellen an TVHeadend anbinden und mit den gerade eingerichteten Kanälen verknüpfen.

Hier führen viele Wege nach Rom. Um den Weg möglichst einfach zu gestalten, gibt es in der Datenbank passende M3Us für verschiedene EPG Anbieter. Im Moment beschränkt sich das allerdings auf den allseits beliebten Rytec EPG. Diesen gibt es unter immer wieder anderen Mirror-Adressen, so dass ihr hier am besten selbst Google bemüht. Für die frei empfangbaren Sender empfiehlt sich die rytecDE_Basic Datei.

Diese müsst ihr mit einem Grabber in TVHeadend importieren. Auch hier gibt es vielfältige Möglichkeiten. Am flexibelsten ist vermutlich das Modul External: XMLTV, das ihr direkt in den Grabber Modulen aktivieren könnt.

Nun müsst ihr nur noch die Daten an die angegebene Datei streamen. Dazu könnt ihr euch ein einfaches Script bauen. Eine gute Vorlage findet ihr z.B. hier: https://www.kodinerds.net/index.php/Thread/59348-SHELLSCRIPT-Rytec-EPG-Grabber-für-TvHeadend/

Beim Anlegen des IPTV Automatic Networks benutzt ihr einfach die passende URL. Im Fall vom angesprochenen EPG Anbieter wäre das https://db.iptv.blog/multicastadressliste/tvheadend/rytecDE_Basic

Dann scannt ihr wieder und nachdem ihr die Services gemapped habt, sollten die Kanäle direkt mit den EPG Kanälen verknüpft sein.


Ggf. müsst ihr danach noch mal einen EPG importieren.

In den Logs solltet ihr dann in etwa sowas sehen

2020-02-15 17:42:51.336 xmltv: xmltv: grab took 1 seconds
2020-02-15 17:42:53.216 xmltv: xmltv: parse took 1 seconds
2020-02-15 17:42:53.216 xmltv: xmltv:  channels   tot=   73 new=    0 mod=    0
2020-02-15 17:42:53.216 xmltv: xmltv:  brands     tot=    0 new=    0 mod=    0
2020-02-15 17:42:53.216 xmltv: xmltv:  seasons    tot=    0 new=    0 mod=    0
2020-02-15 17:42:53.216 xmltv: xmltv:  episodes   tot=    0 new=    0 mod=    0
2020-02-15 17:42:53.216 xmltv: xmltv:  broadcasts tot=12669 new=12669 mod=    0

Und der EPG sollte gefüllt sein:

3 Like

Ich wollte hier mal die Enigma2 Boxen ins Spiel bringen, z.B. meine Dreambox DM800seV2. Bis zur Abschaltung von “EntertainTV” hat das dort auch funktioniert, allerdings bekomme ich die SSM-Streams ums Verrecken nicht ans laufen.

Während die Wiedergabe auf iPhone, also iOS oder Andriod-Systemen, als auch dem PC mit den hier zur Verfügung gestellten Listen einwandfrei funktionieren, will die Dreambox einfach nicht.

Hier ein Beispiel der Syntax für das Abspielen:

- hat bisher funktioniert (geht aber jetzt natürlich nicht mehr):
#NAME Telekom IPTV EPG: KD
#SERVICE 1:64:0:0:0:0:0:0:0:0::Entertain FTA [EPG KD - Region Bayern]
#DESCRIPTION Entertain FTA [EPG KD - Region Bayern]
#SERVICE 1:0:19:2B5C:41B:1:FFFF014A:0:0:0:rtp%3a//@239.35.10.1%3a10000:Das Erste HD
#DESCRIPTION Das Erste HD
#SERVICE 1:0:1:7032:41B:1:FFFF014A:0:0:0:rtp%3a//@239.35.10.58%3a10000:one HD
#DESCRIPTION one HD

- funktioniert nur, wenn zur gleichen Zeit der gleiche Sender auf VLC oder auch MR läuft:
#NAME Entertain TV EPG: KD
#SERVICE 1:64:0:0:0:0:0:0:0:0::Entertain FTA [EPG KD - Region Bayern]
#DESCRIPTION EntertainTV FTA [EPG KD - Region Bayern]
#SERVICE 1:0:19:2B5C:41B:1:FFFF014A:0:0:0:rtp%3a//87.141.215.251@232.0.20.35%3a10000:Das Erste HD
#DESCRIPTION Das Erste HD
#SERVICE 1:0:1:7032:41B:1:FFFF014A:0:0:0:rtp%3a//87.141.215.251@232.0.20.49%3a10000:one HD
#DESCRIPTION one HD

Wenn jemand eine Lösung hat, können wir die Enigma2-Boxen mit aufnehmen.

Hier gab es übrigens eine längere Diskussion, wo viel Informationen diesbezüglich gesammelt wurden:
https://www.multimediaforum.de/threads/462330-iptv-bouquets

Gruss -LERNI-

Das hatten wir hier doch schon mal :thinking:

Gut möglich. Das ist die klassische Starthilfe für Clients ohne SSM.
Richtung WAN kommt der Multicast oft nur mit SSM Option. Kann der Client das nicht, bleibt es beim Wunsch nach der Gruppe im LAN. Kommt dann der VLC und will die gleiche Gruppe mit SSM geht der Request im WAN raus, die Pakete kommen am Router und Switch an und der merkt “Oh, die Gruppe wollte der andere Client doch auch” und leitet die weiter.

Die Frage ist halt, wie bringt man den Client dazu selbst die richtige Anfrage zu stellen. Und da ist die Frage auf die ich leider auch keine Antwort habe: ist das nur eine Frage der richtigen Syntax oder kann es der Client wirklich nicht und braucht es ein Software Update.
Ich fürchte das kann letztlich nur der Software Entwickler beantworten. Oder wenns Open Source ist kann man selbst nachschauen. Nur dazu kenne ich mich zuwenig mit Dreamboxen, OpenATV und Co aus.

In dem verlinkten Thread war ja auch mal von udpxy die Rede. Den gibts mittlerweile in einer SSM tauglichen Variante. Nur der muss dann wahrscheinlich auf einem extra Gerät laufen. Wenn man das hat wäre auch z.B. TVHeadend eine Option, das kann auch den Proxy spielen. Da werde ich demnächst vielleicht mal ein paar warme Worte verlieren, wenn ich selbst dahinter gestiegen bin :innocent:

2 Like

Auf den Dreamboxen läuft doch Linux, da müsste es doch eigentlich passende Lösungen geben.

Hallo!
Ich habe eine Frage bzgl. der unverschlüsselten Sender auf meinen Panasonic-TVs.
Bisher war es so, dass ich die Entertain-Streams am TV empfangen konnte.
Die funktinieren bekanntlich nicht mehr.
Das Problem ist nun, dass meine Panasonic-TVs offenbar mit den neuen Streams nicht zurechtkommen. Im Sendersuchlauf wird einfach kein Sender gefunden (habe ich wie vorher auch auf dem USB-Stick eingetragen, nur mit den neuen Adressen).
Hat jemand Erfahrung oder kann einen Tipp geben, damit wieder am TV der Stream empfangen wird?
Gruß,
Mark

Hat von euch jemand ffmpeg-basiert (das ist Kodi PVR IPTV Simple Client - also ohne Umweg über tvh, enigma2, u.U tvheadend mit ffmpeg-pipe, oder halt ffmpeg auf der Kommandozeile) die neuen Adressen hell gekriegt? Bei mir immer nur exakt 2 Minuten 10 Sekunden. Außer gleichzeitig läuft der Stream im Receiver oder auf VLC. Viele Konfigurationen habe ich hier beschrieben https://www.kodinerds.net/index.php/Thread/68436-MagentaTV-unter-Kodi-Tvheadend-VLC-ffmpeg-Enigma2/?postID=567706#post567706

Eine Lösung habe ich nicht ganz, aber paar möglicherweise hilfreiche Beobachtungen:

#NAME Magentatv
#SERVICE 5002:0:19:2B5C:41B:1:FFFF0000:0:0:0:rtp%3a//@232.0.20.35%3a10000?sources=87.141.215.251:Das Erste HD
#DESCRIPTION Das Erste HD
#SERVICE 5002:0:1:6DCA:44D:1:FFFF0000:0:0:0:rtp%3a//@232.0.10.35%3a10000?sources=87.141.215.251:Das Erste
#DESCRIPTION Das Erste
#SERVICE 5002:0:19:2B66:437:1:FFFF0000:0:0:0:rtp%3a//@232.0.20.234%3a10000?sources=87.141.215.251:ZDF HD
#DESCRIPTION ZDF HD

Wird bei mir für ca. 2 Minuten hell, dann dunkel (oder halt, wie schon oben beschrieben, der Stream läuft noch anderswo). Hängt vielleicht von der E2-Distribution ab, aber der Stream-Typ 1 bei dir (bei mir 5002) wundert mich, ist normalerweise für “pures TS” reserviert. Die anderen Ziffern oben vor der UrL sind nicht ganz so entscheidend - die von mir genutzten passen auf Vodofone Kabel-Anschuss: mit denen wird dann zum Seender im Kabelnetz veknüpft, beispielsweise für EPG. Bei meiner Distribution steht die 5002 für “Service-App nutzen” wohinter sich ffmpeg verbirgt.

Ja, das geht. Hat halt den Nachteil, dass noch ein Server immer im Hintergrund mitlaufen muss, und dass der gesamte Netztraffic erhöt wird. In dem Zusammenhang noch eine Beobachtung: VLC läuft im LAN einwandfrei mit den neuen Adressen. Im WLAN kriege ich auch alle 2 Minuten Abbruch wie bei ffmpeg. Klar, WLAN ist nix wird man gleich sagen … Aber, gehe ich auf tvh von VLC aus ist alles stabil, auch im WLAN (und wohlgemerkt ohne Transkodierung der Nutzdaten in tvh, tvh ist im LAN). Ich weiß, dass früher auch mit VLC stabil im WLAN auf die Streams zugreifen konnte. Bin mir leider nicht mehr sicher, ob das jetzt temporäre Phänomene sind oder ob das mit der Umstellung der Adressen zusammen hing.
Habe mir die SSM RFC mal angesehen - das ist keine leichte Kost, wenn man bislang nur einfache Sockets programmiert hat. Frage mich überhaupt: Macht das ganze Handling das OS oder die Anwendung?

Noch ne weitere Beobachtung: vlc nimmt auch das Format
rtp://@232.0.20.35:10000?sources=87.141.215.251 Dann kriege ich auch im LAN nach 2 Minuten Abbruch.

interessante Beobachtungen, dass die ffmpeg Syntax mit sovielen Clients funktioniert… probier mal ob es dann auch mit udp:// statt rtp:// besser klappt.

1 Like

So, jetzt noch mal vom PC eine etwas längere Antwort

Das macht alles das Betriebssystem. Socketseitig musst du nur eine andere Socketoption mit anderem struct nutzen und die Source Adresse mit angeben.

Deshalb ist das ffmpeg Verhalten ja auch so ungewöhnlich. Das rtp Modul scheint den Join schon richtig zu machen, stellt dann aber nach ein paar ms zurück auf das klassische Multicast ohne Source-Option. Von den Logs ausgehend sieht es irgendwie so aus, als würde der intern noch mal eine SDP bauen - dort fehlt die Source Option - und dann auf diese umstellen :man_shrugging:

Was die anderen Clients angeht (und auch das VLC via WLAN) müsste man vielleicht auch einfach mal mit tcpdump/Wireshark schauen, was da igmp-mäßig abläuft. Wenn nach 2:10min Schluss ist, kommen entweder die IGMP Queries beim Client nicht an, er beantwortet sie nicht oder die Antworten kommen beim Router nicht an. Aber wie gesagt, diese zu beantworten ist alles Sache des Betriebssystems. Nur wenn die Software dem Betriebssystem sagt “IP_ADD_MEMBERSHIP”, dann nimmt es die Source Option raus - sofern sie vorher vorhanden war - und dann funktionieren die neuen Streams meist nicht mehr (Ausnahmen gibts allerdings, wenn der DSL Router, MSAN und der BNG kein Problem damit haben auch IGMPv3 Requests ohne SSM zu bearbeiten).

1 Like

Bingo! Danke sehr - auch für die ausführliche Antwort. Wie bist du drauf gekommen?

Also auf Linux mit Kommandozeile:

ffmpeg -i udp://@232.0.20.35:10000?sources=87.141.215.251 -map 0 -c copy -copy_unknown -f mpegts d.ts

Ein-Stündige Aufnahme gemacht - schein perfekt funktioniert zu haben. Unter Windows scheint es auch zu gehen.

Enigma2: Geht mit Service-Typ 5002 in meiner Box. Dazu muss die sogenannte Serviceapp installiert sein.

Wer will, kann mal Anlage probieren. Basiert auf älterer Liste von hier (allerdings Reihenfolge nach meinem Gusto), habe nur mal neue Sender hinzugefügt (Voxup), aber keinen kompletten Abgleich gemacht mit der aktuellen Liste. Ist optimiert für Vodafone Kabel (dann werden Logos und EPG richtig angezeigt). Bei Bedarf kann ich das auch für Astra liefern, wenn mir jemand seine lamedb zur Verfügung stellt.
userbouquet.magentatv.tv.zip (1,6 KB)

VLC: udp…sources geht nicht (rtp…Sources-2min10) - Aber da geht ja die normale rtp-Methode

Kodi PVR Simple IPTV Client: muss ich noch genauer testen. Brach jetzt nach 2 Minuten ab.
EDIT: Kodi geht wohl nicht mit PVR Simple IPTV Client, obwohl da auch ffmpeg genutzt wird. Hängt vielleicht von Version/Kompilier-Optionen ab. Was ich sah, war wohl wegen parallelen Tests mit gleichem Stream. Kodi mit tvheadend und entsprechendem Kodi-Client funkt natürlich.

Die ausführlichere Antwort muss ich mir mit Ruhe zu Gemüte führen. Kennt von euch jemand das Ähnliche Problem mit vlc im WLAN. Am Rechner wird es kaum liegen - Kabel rein, und es geht. (Wie gesagt, liegt es auch nicht an der WLAN-Bandbreite, über tvh geht es ja perfekt.) Mein Router: Speedport W921V.

Im Grunde durch ausprobieren. Man sieht relativ schnell ob es funktioniert, wenn man tcpdump nebenher laufen lässt und auf igmp filtert.

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

Habe dann auch mal neben dem relativ alten ffmpeg, das bei Ubuntu dabei ist, aus dem github Master eine neue Version gebaut - verhält sich aber genauso.

1 Like

Bin leider nicht so tief im Thema wie Du, daher jetzt mal die für Dich vermutlich dumme Frage: Was muss ich auf meiner Dream nachinstallieren und ggfs. starten, dass ffmpeg als Service 5002 bentutzt wird?

Wenn ich in der bisherigen Syntax “rtp” mit “udp” ersetze (siehe meinen alten Beitrag) und der Stream gleichzeitig woanders läuft, bekomme ich massive Bildruckler und Klötzchenbildung, was auf ein hohe Auslastung der CPU bzw. des Netzwerkes hinweise würde, kann ich mir aber nicht vorstellen.

Gruss -LERNI-

Bei echter Dreambox kann ich leider nicht mit reden. Wenn das vorher (alte Adressen) bei dir geklappt hat mit Service-Typ 1, kannst ja mal meine Anlage aufmachen und mit Editor deiner Wahl (z.B. Notepad) alle 5002 ersetzen durch 1. Vielleicht geht es dann von Natur aus auf der Dreambox.
Auf meiner open Enigma basierten Box geht es nicht mit 1, nur mit 5002. Zu finden unter Menü->Einstellungen->System->Serviceapp, wo man Serviceapp konfigurieren kann (ich musste es aber nur aktivieren, wenn ich mich recht entsinne).
Sonst Mal in Dream Forum nachfragen.

1 Like

Ich glaub eher, dass der dann wirklich meint es ist direkt UDP. War früher beim VLC auch so und ich bin selbst erstaunt, dass ffmpeg sich nicht auch so verhält - das ist eher “Glückssache” (oder intern wird der gleiche Decoder verwendet, der eben auch den RTP erkennt). Der Client muss den RTP Header zumindest entfernen. Wenn er es direkt als MPEG interpretiert, hast du durch den Header immer wieder Datenmüll drin und dann kommt es eben zu den Störungen, weil ein MPEG Decoder damit nichts anfangen kann.

2 Like

Habe ich natürlich schon probiert, aber ohne Erfolg. Wenn in das richtig sehe, ist “ffmpeg” in dem “gstreamer”-Plugin integriert und es bedarf vermutlich keiner separaten Installation. Trotzdem, alle Versuche, die Syntax auf die neuen Adressen anzupassen sind bisher gescheitert. Wenn ich mit Wireshark trace, kann ich auch erkennen, dass die Dreambox immer nur “any Source” ins Internet schreit und natürlich keine Antwort bekommt:


Hingegen klappt es mit dem VLC auf dem PC problemlos, da wird die Anfrage korrekt abgesetzt und beantwortet:

Entweder kann es der “gstreamer” tatsächlich nicht, oder die Syntax stimmt nicht.

Gruss -LERNI-

Bei mir ist das noch was anderes als gstreamer. Siehe:


(Was jetzt hervorgehoben ist, soll nix bedeuten). Du siehst die Nummern 5001 und 5002. Bei mir laufen die Streams mit 5002. GstPlayer liegt auf 5001. Meines Wissens liegt die native IPTV-Abspiellogik auf 4097. Kannst ja mal die ersten 7 Sender von 4097 bis 5003 durchnummerieren nach #SERVICE.

Nachdem was @Grinch gesagt hat, wird die 1 (die jedenfalls bei mir nur bei echtem ts funktioniert) wohl auch bei dir kaum gehen. Hatte allerdings verstanden, dass das bei dir mit den alten Entertain-Streams ging?

Danke, mit udp, das war der richtige Gedanke. Jetzt läuft alles wunderbar und weder Bild noch Ton ruckeln.:medal_sports::grinning:

AVM hat das Verzeichnis 1/ schon mal aktualisiert:
http://download.avm.de/tv/
Die noch fehlenden Sender haben sie aber (noch?) nicht aufgenommen.

http://download.avm.de/tv/tv1.html
sollte wieder funktionieren.