Unsere MR und VLC sind am Laufen, und das ist auch gut so (wenn ich das hier drüber so lese). 
MR und VLC laufen hier auch tadellos. Ich wollte aber gerne TVHeadend zum Laufen bringen, damit ich es in Plex einbinden kann. So spare ich mir effektiv Magenta TV mobil… 
Hi, ich habe mich hier durchgelesen und versucht alles zu befolgen allerdings ohne erfolg 
auch bei mir funktioniert es bspw. mit vlc tadellos.
Interface ist korrekt eingestellt, URLs passen und ich habe version 4.3-1789
Hier mal ein paar logs
tcpdump
17:02:24.201258 IP 192.168.178.65.53618 > 46060d6067bc.9981: Flags [.], ack 21490, win 501, options [nop,nop,TS val 1982303909 ecr 3164969917], length 0
17:02:24.383620 IP 46060d6067bc.41180 > 172.18.255.255.65001: UDP, length 20
17:02:24.397263 IP 46060d6067bc > igmp.mcast.net: igmp v3 report, 2 group record(s)
17:02:24.590476 IP 46060d6067bc.41180 > 172.18.255.255.65001: UDP, length 20
17:02:25.202291 IP 46060d6067bc.9981 > 192.168.178.65.53618: Flags [P.], seq 21490:21494, ack 1, win 501, options [nop,nop,TS val 3164970918 ecr 1982303909], length 4
17:02:25.202390 IP 46060d6067bc.9981 > 192.168.178.65.53618: Flags [P.], seq 21494:23231, ack 1, win 501, options [nop,nop,TS val 3164970918 ecr 1982303909], length 1737
17:02:25.202833 IP 192.168.178.65.53618 > 46060d6067bc.9981: Flags [.], ack 21494, win 501, options [nop,nop,TS val 1982304911 ecr 3164970918], length 0
17:02:25.202899 IP 192.168.178.65.53618 > 46060d6067bc.9981: Flags [.], ack 23231, win 496, options [nop,nop,TS val 1982304911 ecr 3164970918], length 0
17:02:25.207282 IP 192.168.178.65.53822 > 46060d6067bc.9981: Flags [P.], seq 24329:26735, ack 23083, win 501, options [nop,nop,TS val 1982304915 ecr 3164965954], length 2406
17:02:25.207314 IP 192.168.178.65.53826 > 46060d6067bc.9981: Flags [P.], seq 12377:14835, ack 2134, win 501, options [nop,nop,TS val 1982304915 ecr 3164965946], length 2458
17:02:25.207363 IP 46060d6067bc.9981 > 192.168.178.65.53822: Flags [.], ack 26735, win 498, options [nop,nop,TS val 3164970923 ecr 1982304915], length 0
17:02:25.207377 IP 46060d6067bc.9981 > 192.168.178.65.53826: Flags [.], ack 14835, win 498, options [nop,nop,TS val 3164970923 ecr 1982304915], length 0
17:02:25.207433 IP 192.168.178.65.53824 > 46060d6067bc.9981: Flags [P.], seq 12348:14835, ack 1793, win 501, options [nop,nop,TS val 1982304915 ecr 3164965948], length 2487
17:02:25.207672 IP 46060d6067bc.9981 > 192.168.178.65.53826: Flags [P.], seq 2134:2287, ack 14835, win 501, options [nop,nop,TS val 3164970924 ecr 1982304915], length 153
17:02:25.207716 IP 46060d6067bc.9981 > 192.168.178.65.53826: Flags [P.], seq 2287:2356, ack 14835, win 501, options [nop,nop,TS val 3164970924 ecr 1982304915], length 69
17:02:25.207796 IP 46060d6067bc.9981 > 192.168.178.65.53824: Flags [.], ack 14835, win 498, options [nop,nop,TS val 3164970924 ecr 1982304915], length 0
17:02:25.207904 IP 192.168.178.65.53826 > 46060d6067bc.9981: Flags [.], ack 2287, win 501, options [nop,nop,TS val 1982304916 ecr 3164970924], length 0
17:02:25.207916 IP 192.168.178.65.53826 > 46060d6067bc.9981: Flags [.], ack 2356, win 501, options [nop,nop,TS val 1982304916 ecr 3164970924], length 0
17:02:25.208307 IP 46060d6067bc.9981 > 192.168.178.65.53824: Flags [P.], seq 1793:1971, ack 14835, win 501, options [nop,nop,TS val 3164970924 ecr 1982304915], length 178
17:02:25.208350 IP 46060d6067bc.9981 > 192.168.178.65.53824: Flags [P.], seq 1971:2357, ack 14835, win 501, options [nop,nop,TS val 3164970924 ecr 1982304915], length 386
17:02:25.208561 IP 192.168.178.65.53824 > 46060d6067bc.9981: Flags [.], ack 1971, win 501, options [nop,nop,TS val 1982304917 ecr 3164970924], length 0
17:02:25.208572 IP 192.168.178.65.53824 > 46060d6067bc.9981: Flags [.], ack 2357, win 501, options [nop,nop,TS val 1982304917 ecr 3164970924], length 0
17:02:25.210592 IP 46060d6067bc > igmp.mcast.net: igmp v3 report, 2 group record(s)
17:02:25.213868 IP 46060d6067bc.9981 > 192.168.178.65.53822: Flags [P.], seq 23083:23262, ack 26735, win 501, options [nop,nop,TS val 3164970930 ecr 1982304915], length 179
17:02:25.214133 IP 46060d6067bc.9981 > 192.168.178.65.53822: Flags [P.], seq 23262:26447, ack 26735, win 501, options [nop,nop,TS val 3164970930 ecr 1982304915], length 3185
17:02:25.214150 IP 192.168.178.65.53822 > 46060d6067bc.9981: Flags [.], ack 23262, win 501, options [nop,nop,TS val 1982304922 ecr 3164970930], length 0
17:02:25.214355 IP 192.168.178.65.53822 > 46060d6067bc.9981: Flags [.], ack 26447, win 489, options [nop,nop,TS val 1982304922 ecr 3164970930], length 0
tvheadend log
2019-04-24 17:38:40.339 [ INFO] mpegts: playlist.php - (12) 3sat HD in IPTV - scan no data, failed
2019-04-24 17:38:40.339 [ INFO] subscription: 025F: “scan” unsubscribing
2019-04-24 17:38:40.339 [ INFO] mpegts: playlist.php - (496) WDR Aachen SD in IPTV - tuning on IPTV #1
2019-04-24 17:38:40.340 [ INFO] subscription: 0261: “scan” subscribing to mux “playlist.php - (496) WDR Aachen SD”, weight: 6, adapter: “IPTV #1”, network: “IPTV”, service: “Raw PID Subscription”
2019-04-24 17:38:45.339 [ INFO] mpegts: playlist.php - (496) WDR Aachen SD in IPTV - scan no data, failed
2019-04-24 17:38:45.339 [ INFO] subscription: 0261: “scan” unsubscribing
2019-04-24 17:38:45.339 [ INFO] mpegts: playlist.php - (77) TOGGO plus SD in IPTV - tuning on IPTV #1
2019-04-24 17:38:45.340 [ INFO] subscription: 0263: “scan” subscribing to mux “playlist.php - (77) TOGGO plus SD”, weight: 6, adapter: “IPTV #1”, network: “IPTV”, service: “Raw PID Subscription”
2019-04-24 17:38:50.339 [ INFO] mpegts: playlist.php - (77) TOGGO plus SD in IPTV - scan no data, failed
2019-04-24 17:38:50.339 [ INFO] subscription: 0263: “scan” unsubscribing
2019-04-24 17:38:50.340 [ INFO] mpegts: playlist.php - (1) Das Erste SD in IPTV - tuning on IPTV #1
2019-04-24 17:38:50.340 [ INFO] subscription: 0265: “scan” subscribing to mux “playlist.php - (1) Das Erste SD”, weight: 6, adapter: “IPTV #1”, network: “IPTV”, service: “Raw PID Subscription”
2019-04-24 17:38:55.339 [ INFO] mpegts: playlist.php - (1) Das Erste SD in IPTV - scan no data, failed
2019-04-24 17:38:55.339 [ INFO] subscription: 0265: “scan” unsubscribing
waere super falls jemand noch die ein oder andere idee hat die ich probieren koennte 
Kannst du den tcpdump in eine Datei schreiben, dass man sich das in schön in Wireshark angucken kann und insbesondere die Daten komplett sind? 
also mit -w dateiname -s 0
So spontan sehe ich 2 IGMP v3 Requests mit 2 Gruppen drin… da nichts weiter dabei steht, gehe ich davon aus, dass die Source-Adresse für SSM fehlt. Aber da man nicht mal sieht welche beiden Gruppen das sind ist eine Diagnose schwierig
Und ggf. auch mal das LogLevel auf DEBUG erhöhen, scheint im Moment auf INFO zu stehen.
Hallo in die Runde und ein gesundes neues Jahr wünsche ich allen.
Auch bei mir war der IP-Stream plötzlich weg.
Ich habe zwar den Telekom-Reciver 401, welcher auch weiter funktionierte, nur, ich nehme mir Filme auf und vom Reciver bekommt man die Aufnahmen nicht zum archivieren runterkopiert, ist mir jedenfalls nicht bekannt.
Kurtzum, ich benutze einen Raspberry 3 B+ mit OSMC und TVHeadend, welcher bis zur Abschaltung des alten Entertain-Stream hervorragend lief, incl. Aufnehmen.
Dann fand ich gestern diesen Blog und sah, daß in der Datenbank neue IP-Adressen vorhanden waren.
Ich bin zwar 58 Jahre alt, eine Frau und habe vor Technik keine Angst.
Also fing ich an, im TVHeadend-Backend auf dem Rechner, die neuen Adressen per Hand einzutragen, zunächst ohne Erfolg, da ich vergaß’, die alte Entertain-URL zu löschen und beim Neustart des Raspi die alte Entertain-URL wieder eingelesen wurde und meine Änderungen löschte.
Also, löschte ich die alte Entertain-URL und ersetzte die Streamlinks mit den neuen Streamlinks der HD-Sender, aktivierte die Schnittstelle eth0, setzte den Service und mappte dann jeden von Hand eingetragenen/geänderten Kanal und siehe da: Es funktioniert hervorragend, wie es mit dem alten Entertain-Streams auch funktionierte. Aufnehmen klappt auch wieder. Der Aufwand hat sich gelohnt, auch die anfänglichen Fehlschläge.
Ich möchte mich hier ganz recht herzlich beim Ersteller der neuen Magenta-Streams bedanken.
LG, Mylène
4 „Gefällt mir“
Kurze Anmerkung/Ergänzung zum Thema TVHeadend, weil damit wohl einige Probleme haben. Prinzipiell funktionieren die neuen Adressen auch mit TVHeadend (ab Version 4.1 oder so wird SSM unterstützt). Allerdings scheint da noch irgendein Bug beim Import von M3Us zu sein.
Legt man ein IPTV Network an und nimmt z.B. die https://db.iptv.blog/multicastadressliste/m3u als URL, werden alle Sender zwar als “Muxes” angelegt, allerdings wird dabei die URL verändert/zerstört. TVHeadend entfernt die Source Option, sprich aus der URL rtp://87.141.215.251@232.0.20.35:10000 wird plötzlich rtp://@232.0.20.35:10000. Öffnet man den Mux im Webfrontend und ändert die URL wieder ab, fügt also die 87.141.215.251 wieder ein und speichert, bleibt die URL dann plötzlich erhalten und dann sollte auch der Scan und das Mapping funktionieren.
Leider eine recht mühsame Angelegenheit das für alle Sender zu machen. Wenn hier also jemand eine Idee hat, was schiefläuft und wie man das vereinfachen kann: raus damit 
1 „Gefällt mir“
Mal ne Frage…
Welche Adresse gibt man eigentlich als Quelle für die EPG Daten an?
Wenn man z.B. per Kodi IPTV nutzen möchte.
EPG Daten ist der nächste spannende Punkt 
Also die Streams enthalten mal eine EIT, allerdings nur für die laufende und nachfolgende Sendung. Darüber hinaus bin ich mit meinen TVHeadend Experimenten noch nicht gekommen. Hab das erst gestern mal spaßeshalber installiert, weil ich gesehen habe, dass ich pro Tag 35.000 Abrufe der Playlist von TVHeadend Clients habe (die rufen die Playlist wohl alle Stunde ab). Da könnten also durchaus noch mehr Leute aufschlagen und die wissen sicher auch, wie man den EPG da sinnvoll reinbekommt
2 „Gefällt mir“
Kann man das nicht durch automatisches Suchen und Ersetzen machen? Kann doch sogar ein einfacher Text-Editor.
Das ist im Web-Frontend, da kannst du immer nur einen Kanal gleichzeitig öffnen. Bzw. du kannst auch mehrere gleichzeitig ändern, aber dann bekommen alle den gleichen Wert. Letzteres ist sinnvoll, wenn man die Netzwerkkarte setzen will - die steht natürlich auch nicht in der M3U.
Ich hab mich jetzt noch nicht so genau damit befasst, aber so wie ichs verstehe kann TVHeadend wohl auch erweiterte Parameter aus der M3U rauslesen, nur hab ich noch keine Beschreibung dafür gefunden. Und auch die Config exportieren habe ich noch nicht gefunden - soll aber wohl irgendwo gehen 
2 „Gefällt mir“
Falls es jemand noch nicht kennt
1 „Gefällt mir“
Iiiinteressant… die nutzen für TVHeadend wohl ffmpeg als Proxy. Das wäre natürlich auch eine Variante die SSM Streams unterzuschieben, wenn die “original Urls” nicht funktionieren… zwar etwas durch die Brust ins Auge, aber OK. Und die erweiterten tvg-Infos sind auch drin, wie hier.
2 „Gefällt mir“
Ich benutze kein ffmpeg. Geht auch so.
Die .m3u muß nur gelöscht werden, auch keine neue m3u eintragen und dann die einzelnen Sender in den Muxes mit den neuen Sender-URL’s ausgetauscht werden und dabei bei jedem Sender die Schnittstelle auf eth0 setzen, was vorher nicht nötig war, jetzt aber ohne eth0 nicht funktioniert. Also; Schnittstelle : eth0 aktivieren, bei jedem geänderten Sender.
Bei mir hat das so geklappt und es laufen alle von mir geänderten HD-Sender wieder, incl. EPG.
Wenn ichs jetzt richtig verstehe und so wars auch bei mir, man musste bei jedem Sender einzeln die URL noch mal anpassen, oder?
Das sollte halt irgendwie nicht sein, wenn man schon die M3U importieren kann 
Ausserdem würde das IPTV Automatic Network die Playlist auch regelmäßig runterladen und automatisch aktualisieren.
Hab mal etwas mit der ffmpeg-pipe Variante rumgespielt und das funktioniert ganz gut (auch ohne manuelle Anpassungen danach). Man schlägt sogar 2 Fliegen mit einer Klappe - denn ffmpeg ist die Schnittstelle egal (zumindest mal wenn man nur eine hat ). Nachteil ist allerdings, dass ffmpeg natürlich sämtliche “Service-Daten” im Stream entfernt, also sowas wie Service Name, Provider Name, Stream Typ etc. Das muss man dann alles in der Playlist wieder angeben. Und ich schätze mal rein von der Performance ist das auch nicht gerade förderlich, wenn ffmpeg den Stream empfängt, Audio/Video rauszieht und dann wieder einen neuen Stream erstellt. EIT, Videotext und Untertitel wäre auch die Frage, ob die dann enthalten sind. Hab ich noch nicht geguckt. Evtl kann man ffmpeg auch noch beibringen den Stream komplett durchzuschleifen.
Die zusätzlichen Parameter, wie das Logo, übernimmt er aber schonmal. Die ID für den EPG hab ich noch nicht drin, da muss ich mir erstmal überlegen wie ich das mit dem Mapping mache. Ausserdem hat TVHeadend natürlich wieder andere EPG Import Scripte Da soll wohl “XMLTV: German speaking area (Egon zappt)” sehr gut funktionieren
1 „Gefällt mir“
Naja, wie ich schrieb, habe ich die 19 Sender von Hand geändert. Ist eine Menge Arbeit, doch der Erfolg hat mich belohnt. Aus IPTV Automatic Network habe ich die .m3u rausgelöscht und in den Muxes dann meine HD-Sender händisch mit den Links aus der Datenbank hier ersetzt. Durch eth0 ist wohl kein ffmpeg notwendig und alle Daten gehen durch. Natürlich noch die Services machen und mappen. Mehr tat ich nicht, nur bis ich es rausfand, dauerte lange…lol.
EPG scripte nehme ich mehrere aus der Interne EPG-Liste. Funktioniert alles Bestens.
Vielleicht nehme ich mir die Tage mal die Zeit und probiere die neue .m3u aus. Im Moment funktioniert alles.
Dann lass es besser 
Wie gesagt, mit der M3U werden im Moment noch die Adressen zerschossen. Mit dem Automatic Device entsprechend alle 60 Minuten aufs Neue 
ffmpeg funktioniert zwar prinzipiell, aber da hab ich auf meinem NAS dann 40% CPU Last beim Streamen an einen Client, 30% von ffmpeg und noch mal 10% von tvheadend. Nehme ich direkt die rtp URL hab ich 15% von TVHeadend. Da auf meinem NAS noch andere Dinge laufen hab ich bei ffmpeg auch immer wieder Bildfehler drin, wenn gerade die CPU Last hoch ist. Bei rtp direkt ist mir das noch nicht aufgefallen. Also ich würde schon bevorzugen direkt die rtp-URL zu benutzen… wenn sie nur richtig importiert würde 
1 „Gefällt mir“
Hab für das rtp-TVHeadend Thema mal einen Bug erstellt: https://tvheadend.org/issues/5843
1 „Gefällt mir“
Hätte ich auch selber drauf kommen können, einfach mal die Entwicklerversion installieren. Mit TVHeadend 4.3 vom “unstable” branch tritt der Fehler nicht auf. Zumindest nicht auf meiner Testkiste, einem Ubuntu 19.10. Mal schauen wie es auf dem NAS mit Ubuntu 18.04 LTS läuft.
1 „Gefällt mir“
Und mit TVHeadend 4.3 gibts den German TV von Egon zappt wieder nicht mehr, dafür xmltv.se - nur haben die natürlich wieder andere IDs für die Sender… Also das Mapping der Sender auf EPG wird wahrscheinlich auch noch ein spannendes Thema.
1 „Gefällt mir“