Beiträge von codit

@Ronny : Mit TVH läuft Magenta inklusive Takaealug-EPG in Libreelec 9.2 gut. Nur das Kopieren der guide.xml geht seit einiger Zeit nicht mehr automatisch, den Fix gibt es wohl erst ab Libreelec 10. Simple IPTV war (vor 2 Jahren) mit Magenta wegen fehlender Unterstützung von Multicast nicht möglich - keine Ahnung ob das Heute noch so ist.

zaddo: Ja mit TVheadend (in Libreelec als Addon enthalten) kannst Du die alten (Entertain) und neuen (Entertain TV) Telekom-Streams empfangen und auch verarbeiten/aufzeichnen. Mit dem Addon IPTVsimple gehen nur die alten Streams. Einzige Voraussetzung: Du hast irgendeinen Entertain-Vertrag bei Telekom (egal welchen!).

Beide Addons können natürlich nur die unverschlüsselten Streams decodieren, die Du bei Entertain ohne Zubuchoption bekommst.

@jNk20

Hier meine versprochene Rückmeldung. Habe einen neuen TVH Server für TelekomEntertainTV aufgesetzt. Die Einrichtung als automatisches IPTV-Netzwerk von einer M3U-Datei funktioniert definitiv NICHT. Bei der automatischen Einrichtung werden die Muxes zwar gefunden, aber die SSM-Adressen der Services verstümmelt.

Beispiel:
- Eintrag aus der M3U:
#EXTINF:-1,tvg-id="ARD.de" tvg-logo="ard.png",(1) Das Erste HD
rtp://87.141.215.251@232.0.20.35:10000
- Service-URL im automatisch angelegten MUX:
rtp://232.0.20.35:10000

Damit kann der SSM-Service dann natürlich nicht aktiviert werden. Mit den "alten" ASM-Streams
(rtp://239...) funktioniert die automatische Einrichtung!

Mein Vorschlag zur Verbesserung Deiner Anleitung bezüglich TVH:
1) Entferne bitte die FFMPEG-Pipes aus den M3U-Einträgen, diese sind definitiv unnötig
2) Weise darauf hin das die Einrichtung als automatisches Netzwerk nur mit den ASM-Streams funktioniert

Ich habe wie gesagt die SSM-Streams manuell eingerichtet. Macht einmalig etwas Arbeit. Auf einen neuen Server kopiere ich die TVH-Konfiguration einfach rüber.

Hab es genau so probiert, wie Du im Punkt 5 Deiner Anleitung beschreibst. Es wurden dann keine Muxes gefunden. Eventuell war in meiner M3u ein Fehler (Zeilenumbruch etc.). Bekomme nächsten Monat aber ein neues Spielzeug, auf dem TVH installiert werden soll. Probiere es dann nochmal und gebe Dir Rückmeldung (Ende Nov, Anfang Dez).

@jNk20
Ich habe 2 TVH-Server auf PI3 in Betrieb. Die 239er Streams laufen bei mir seit 2 Jahren problemlos (und ohne Pipe). Seitdem die TVH-Entwickler mit 4.1-2490 (auf meine Anregung) die SSM-Adressierungsfunktionalität in März 2017 implementiert haben, funktionieren auch die SSM-Streams ohne PIpe. Beide Stream-Typen laufen übrigens unabhängig von der Telekom-Vertragsform (Entertain, EntertainTV, 2 Euro-Variante).

Die von Dir beschriebene Verzögerung habe ich nie beobachtet.
Bei mir geht aber auch nicht alles: Die Verarbeitung einer kompletten M3U habe ich in TVH bis jetzt noch nicht geschafft. Ich muss die Multiplexes einzeln anlegen, bzw. die Konfiguration eines laufenden Servers kopieren.

@jNk20 Schöne Zusammenstellung von Dir!
Deine Ausführungen zu TVHeadend (TVH) kann ich aber so nicht unterschreiben.

1) Für TVH empfehle ich vielmehr jedem, die aktuellen SourceSpecificMulticast Adressen von
Entertain TV (rtp://87.141.215.251@232........:10000/) zu verwenden. TVH kann seit Version 4.1-2490 die SSM-Addressierung verarbeiten. Die aktuellen Streams haben weniger Verzögerung als die alten Entertain Streams mit den 239er Adressen, außerdem wird Telekom in absehbarer Zukunft nur noch die SSM-Streams anbieten.

2) Warum nutzt Du unter TVH eigentlich die ffmpeg-Pipes bei den 239er Streams? Ist unnötig und frisst nur CPU-Leistung.

Grüße
codit

So gute Nachrichten, das TVH-Problem mit SSM ist gelöst: Ab Version 4.1-2490-g2d90cd6 kann TVheadend mit den vollständigen SSM-Adressen von EnternainTV umgehen!

Habe die Version gerade unter Libreelec 8.01 auf einem Raspberry PI2 installiert. Läuft!
Achtung bei der Einrichtung der MUXes muss jetzt im Advanced Menü der Internetadapter eingestellt werden (z.B. eth0). Das hat nur beim manuellen IPTV-Netzwerk funktioniert, nicht beim automatischen.

Die TVH-Version kann übrigens von hier kompiliert heruntergeladen werden (danke an User @CvH ) :
build.mycvh.de/

So gute Nachrichten, das Problem ist gelöst: Ab Version 4.1-2490-g2d90cd6 kann TVheadend mit den vollständigen SSM-Adressen von EnternainTV umgehen!

So gute Nachrichten, das Problem ist gelöst: Ab Version 4.1-2490-g2d90cd6 kann TVheadend mit den vollständigen SSM-Adressen von EnternainTV umgehen!

Habe die Version gerade unter Libreelec 8.01 auf einem Raspberry PI2 installiert. Läuft!
Achtung bei der Einrichtung der MUXes muss jetzt im Advanced Menü der Internetadapter eingestellt werden (z.B. eth0). Das hat nur beim manuellen IPTV-Netzwerk funktioniert, nicht beim automatischen.

Die TVH-Version kann übrigens heruntergeladen werden (danke an User @CvH ) :
http://build.mycvh.de/

Zitat von McStarfighter

Naja, ich bin nicht der Entwickler des Addons, sonst wäre das schon aus reinem Eigennutz in Ordnung gebracht worden!

Oh sorry, war mir nicht klar! Macht es Sinn, den Entwickler mal zu kontaktieren (Kodi Homepage?), der weiß vermutlich nichts von unserm "Deutschem" Problem?

@harom
Ich kann mir nicht vorstellen, dass Dein Problem dieselbe Ursache hat. Das oben diskutierte Problem tritt ja nur auf, weil TVheadend keine 2-teiligen SSM-URLs (Source-Adresse@Stream-Adresse) verarbeiten kann.
Deine IP-Streams haben aber einteilige URLs oder?

@tegger
Mit EntertainTV hast Du bis auf weiteres Pech bei TVheadend, schau mal unter tvheadend.org im Ticket 4229.
Einziger Ausweg wäre den gigpxy zu installieren, der kann seit neuestem IGMP v3. udpxy kann das nicht!

Du kannst aber mal probieren in TVheadend nur die Streamadresse rtp://232.0.20.35:10000 einzugeben. Falls das klappt, hast Du einen "veralteten" Router der nur IGMP v2 kann und die Streamanfrage als ASM-Typ nach draussen gibt (z.B. Fritzbox mit OS6.5 oder 6.6). Der Telekom-Source Node ist schlecht konfiguriert und erlaubt trotzdem den Beitritt zur SSM-Multicastgruppe. Wenn das geht: Glück gehabt! Ab OS6.8 hat AVM IGMPv3 implementiert und gibt ohne Sourcespezifikation in der Adresse nichts mehr nach außen. Der SSM wird an 232 erkannt!

@bolausson
Problem liegt an der IGMPv3 Unterstützung, die in Fritz OS6.80 jetzt für die neuen Telekom SSM-Adressen benötigt wird. AVM hat die Geschichte jetzt standardkonform implementiert. OS6.5 (und wohl auch 6.6) hat auf ein Protokoll zurückgegriffen, das bei SSM nicht angewandt werden soll.

VLC und ffmpeg beherrschen IGMPv3, deshalb laufen die "neuen" Telekom Streams dort. TVheadend kann nur IGMPv2, deshalb geht dort nichts. Vermutlich wird das Problem bei IPTVsimple ähnlich gelagert sein.

@YORKhq :

1) Derzeit kannst Du auf die SSM-Streams von Entertain TV (Entertain 2.0) in TVheadend nur mittels einer Pipe über ffmpeg zugreifen. Dort wo in der MUX-Beschreibung die URL reinkommt setzt Du das angegebenen Pipe-Kommando mit der entsprechenden Stream-Adresse ein. Nochmal danke @Maikl ! Aber.... das läuft auf dem Raspberry nur mit den SD-Streams flüssig, die HD-Streams ruckeln. Eventuell laufen in libreelec8 mit der aktuellen ffmpeg Version auch die HD-Streams vernünftig.

2) Falls in TVheadend irgendwann IGMPv3 Unterstützung dazukommt, geht es wieder. Alternativ könnte man selbst versuchen, mittels der Codebeispiele TVheadend zu erweitern.

3) Eventuell rüstet @McStarfighter ja auch IPTVsimple auf.

Hier gibt es mehr Info:

http://www.tvheadend.org/issues/4229

Mehr zu dem Thema hier:

http://www.tvheadend.org/issues/4229

@x23piracy
Hardware-Decodierung bringt hier nichts, die Bitstreams werden nur kopiert (aus Adressierungsgründen), nicht decodiert.

Das Kopieren des HD-Streams mit ffmpeg überlastet die Rapsberry-CPU. Mit dem SD-Stream ruckelt nichts mehr. Auf die "alten" Entertain Streamm (239....) kann ich ohne pipe zugreifen. Dort laufen auch 2 HD-Streams parallel prima über den Raspberry.

Danke @Maikl auf diese Art kommt man an die Streams heran!

Ich habe das gesamte Pipe-Kommando direkt als URL eingegeben, z.B. für ZDF:

pipe:///usr/bin/ffmpeg -loglevel fatal -i rtp://232.0.20.234:10000?sources=87.141.215.251 -vcodec copy -acodec copy -acodec copy -f mpegts pipe:1

Funktioniert prinzipiell, aber auf die Art verabeitet der Raspberry PI2 die Streams nicht mehr flüssig, sondern ruckelt.

Das Problem mit den "neuen" Entertain TV Streams ist routerspezifisch und hängt von der IGMP Implementierung im Router ab. Betroffen sind z.B. die Fritzboxen mit dem aktuellen OS6.8.
Unter OS6.5 hat noch alles funktioniert. Das Problem tritt auch bei Nutzung von TVheadend auf und wurde im einschlägigen Bereich dieses Forums in 2 Threads bereits (ohne Lösungsansätze!) diskutiert.

Um was geht es? Dazu Text aus einer Anfrage meinerseits im Forum von thheadend.org:

I observed a serious problem with URL handling when using IPTV streams via SSM (source specific multicast). In the MUX I have to specify the stream URL, e.g. rtp://87.141.215.251@232.0.20.35:10000.
Notice, this TV stream is only available if you are connected to the German Telekom network under an appropriate contract. Unfortunately the access to this type of streams is not possible with TVheadend. By network sniffing I noticed that TVheadend delivers only the stream adress 232.0.20.35:10000 to the IP router. Thus IGMP fails to connect to the source node 87.141.215.251.
Is there any Workaround?

Im Prinzip geht es darum, dass der Router bei einer unvollständigen SSM-Streamanforderung (wird am ersten Oktet der Streamadresse erkannt, z.B. 232) ohne den Source-Adressteil standardkonform bei einem ICMP-Server im Netz nach der zuständigen Quelladresse fragen muss. Wird im Fritz-OS6.8 auch so gemacht. Der Telekom-IGMP-Server beantwortet die Anfrage leider nicht.

Unter OS6.5 ging in diesem Fall die Anforderung nach dem Stream an eine beliebige Quelle direkt heraus, 87.141.215,251 fühlte sich zuständig. Das soll natürlich nicht so sein, sonst macht SSM ja keinen Sinn.

Langer Rede kurzer Sinn, dass Problem rührt bei TVheadend daher, dass dort die vollständigen (doppelten) SSM-Streamadressen nicht gehandelt werden. Eventuell ist das bei IPTV simple auch so? Dann wäre es natürlich perfekt, wenn @McStarfighter das Adresshandling vervollständigt.