Gleiches Problem hier. Die neuen EntertainTV/MagentaTV Adressen gehen nicht, der Scan schlägt immer fehl. Hat jemand eine Idee?
TVHeadEnd 4.4.20181215 auf Synology
@mav2010
Kann später mal schauen ob ich TVH als PVR Dienst mit Kodi auf dem QNAP NAS habe.
Bin mir im Moment nicht wirklich sicher…nutze das eigentlich nie.
TVHeadend hatte ich früher doch nicht eingesetzt…sorry.
Hatte früher PVR IPTV simple client benutzt, dieser funktioniert aber nicht mehr bei mir (library konflikte).
Danke trotzdem fürs Nachschauen!
Ist echt seltsam. Mit den alten Entertain Streams funktioniert alles wunderbar. Nur mit den neueren EntertainTV/MagentaTV Streams geht es nicht, obwohl TVHeadend seit Version 4.1 und einem Bugfix alles funktionieren sollte…
Vielleicht dumme Frage aber ich mach es trotzdem mal.
Hat es vielleicht auch mit dieser 87.141.215.251 Adresse versucht? Die muss ja scheinbar vorher eingefügt werden
Im Zweifel müsstest du einfach mal mit tcpdump schauen ob die IGMP Requests überhaupt richtig das NAS verlassen. Wenn die alten Streams gehen stimmt höchstwahrscheinlich etwas mit der SourceIP nicht.
Schon klar, ich verwende bspw. diese Adresse hier als URL in tvheadend: rtp://87.141.215.251@232.0.10.222:10000
Ich habe mal tcpdump laufen lassen mit WDR als Testsender.
Mit der Entertain rtp://@239.35.10.18:10000 Adresse kommt:
09:17:32.991007 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
NAS.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) [gaddr 239.35.10.18 to_ex { }]
Mit der MagentaTV Adresse rtp://87.141.215.251@232.0.10.222:10000 finde ich gar nichts im Dump?!?
Ich würde ja gerne mal in den Log schauen, aber irgendwie legt TVHeadend kein Log File auf meinem Synology NAS an (oder ich bin zu blöd, es zu finden…).
Versuchen die 87er Adresse mal wegzulassen?
rtp://@232.0.10.222:10000 also so eventuell?
Aus dem Gedächtnis (irgendwo gelesen) - daher ohne Gewähr -: tvheadend unterstützt das irgendwie nicht, weglassen bringt aber auch nichts.
Das bringt leider auch nichts. Habe irgendwo gelesen, dass das bei einigen (schlechten) Routern zufällig funktioniert. Bei meiner FritzBox leider nicht…
1 „Gefällt mir“
, dann weiß ich leider auch nicht 
Was ist bitte gemeint mit schlechten Routern?
Der Router ist da glaub ich weniger entscheidend. Ich hab z.B. eine FB7490 und bei mir gehts ohne Angabe der SourceIP (noch). Das Thema steckt denke ich eher im Netz. Wenn man die SourceIP weglässt, dann reichen das die meisten Router erstmal einfach so durch. Sie wissen ja auch nicht, ob da eine sein muss oder nicht (vgl. alte Streams und neue Streams). Spätestens im Backbone der Telekom ist die SourceIP dann aber Pflicht und wenn man Glück hat, sucht sich die Gegenseite basierend auf der Multicast-Gruppe die Source-IP selbst raus oder eben nicht.
Wenn das bei dir nicht funktioniert, dann muss eben zwingend die SourceIP her.
Und jetzt ist die Frage warum du nicht mal das IGMP Paket siehst… also so sollte das aussehen:
10:43:35.682336 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
192.168.2.136 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.10.1 allow, 1 source(s)] [gaddr 232.0.10.1 to_in, 1 source(s)]
Wenn das Paket aber gar nicht auftaucht, dann stimmt entweder was mit TVHeadend nicht, sprich er erkennt die Syntax nicht richtig oder was auch immer - das wäre eine Sache fürs Log. Oder das Betriebssystem kommt damit nicht klar.
Ich weiss jetzt nicht was so ein Synology an Tools hat um mal Multicast anzufordern? Hast du dumprtp6? Wäre so das einfachste Tool, das auch mit relativ einfachen Mitteln aus dem Quellcode gebaut werden kann.
dumprtp6 -i eth0 -s 87.141.215.251 232.0.10.1 10000
Danke, das war die Erklärung.
dumprtp6 gibt es leider nicht für Synology. Aber ich habe den DEBUG Log von TVHeadend endlich an bekommen. Bei den neuen Streams kommt das hier:
2018-12-21 10:52:18.882 [ DEBUG] mpegts: rtp://232.0.10.222:10000 in IPTV Automatic Network - add raw service
2018-12-21 10:52:18.883 [ DEBUG] service: 1: rtp://232.0.10.222:10000 in IPTV Automatic Network si 0x7fcf7c01e8a0 <unknown> weight 0 prio 11 error 0 (OK)
2018-12-21 10:52:18.883 [ ERROR] iptv: rtp://232.0.10.222:10000 in IPTV Automatic Network - cannot find ip address for interface (null) [e=Not a directory]
Wenn ich ihn manuell auf eth0 zwinge, kommt das:
2018-12-21 10:54:54.029 [ ERROR] iptv: rtp://232.0.10.222:10000 in IPTV Automatic Network - cannot find ip address for interface eth0 [e=Cannot assign requested address]
Ist jetzt nicht sonderlich hilfreich, aber hab den IPTV simple client (Kodi 17.6) wieder zum laufen bekommen.
Und dort funktionieren die MagentaTV Streams auch nicht, es gehen nur die alten.
Log habe ich jetzt nicht finden können.
Tvheadend server ist bei mir so nicht installierbar, bräuchte ein dev qpkg und obs dann geht keine Ahnung.
Interessant… ich hab jetzt einfach mal nach der “cannot find ip address”-Fehlermeldung gesucht und wurde nur hier fündig: https://github.com/tvheadend/tvheadend/blob/66d6161c563181e5a572337ab3509a835c5a57e2/src/udp.c
Allerdings 3x 
In allen 3 Fällen tritt das aber auf wenn udp_get_ifaddr -1 zurückgibt… also hab ich die Funktion mal gesucht und die gibt -1 zurück wenn entweder kein Name übergeben wird (NULL) - von daher musst du wohl wirklich das Interface zuweisen - oder wenn ioctl <0 zurückgibt. Und das sollte nur der Fall sein, wenn er kein Interface mit dem Namen findet. Oder es hat keine IP oder es hat mehrere IPs?
Kannst du mal ein ip addr show ausführen? Gibts da eth0 mit der richtigen LAN-IP? Bin jetzt mit der Netzwerkkonfiguration von Synology leider nicht vertraut
So, danke für das Stupsen in die richtige Richtung, jetzt habe ich es hinbekommen.
Hier der gewünschte Output:
admin@NAS:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000
link/ether 00:11:32:95:e8:22 brd ff:ff:ff:ff:ff:ff
4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1
link/ether 5a:f2:33:86:eb:5f brd ff:ff:ff:ff:ff:ff
6: ovs_eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1
link/ether 00:11:32:95:e8:22 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.100/24 brd 192.168.178.255 scope global ovs_eth0
valid_lft forever preferred_lft forever
inet6 fe80::211:32ff:fe95:e822/64 scope link
valid_lft forever preferred_lft forever
Dabei hat mich stutzig gemacht, dass die IP Adresse (192.168.1.100) nicht an eth0, sondern an ovs_eth0 vergeben ist. Ein bisschen forschen hat ergeben, dass es sich dabei um ein VLAN handelt, das angelegt wurde, weil ich eine virtuelle Maschine installiert habe. Manuelles Umbiegen in TVHeadend auf ovs_eth0 als Interface hat dann den gewünschten Erfolg gebracht… 
Bleibt die Frage, warum es nicht out of the box funktioniert bzw. warum er nicht automatisch ovs_eth0 hernimmt…
Danke, Grinch, für die Hilfe beim Nachdenken!
1 „Gefällt mir“
Das mit der automatischen Erkennung des richtigen Interfaces ist auch so ein zweischneidiges Schwert. Da brauchst nur mal in die Kommentare zur Multicastadressliste schauen bei wievielen das beim VLC nicht richtig funktioniert. Da ist mir persönlich lieber man stellt es gleich von Hand ein. Gerade beim Linux Kernel kann die Netzwerkkonfiguration beliebig komplex werden, ich glaube da wird ein Automatismus für alle schwer. Erschwerend kommt dann noch dazu, dass man zum Setzen einer SSM Gruppe nicht den Interface Index (auch ein Konstrukt mit Vor- und Nachteilen), sondern die IP angeben muss - da diese IP Absender des IGMP Requests ist.
Als TVHeadend könnte man das aber natürlich schöner lösen, z.B. mit einem Dropdown der verfügbaren IPs und deren Interfaces. Das wäre in deinem Fall nämlich nur ein Eintrag gewesen und den hätte man dann als Default gleich auswählen können