Beiträge von Nuems

    Ich habe noch weitere Testrunden durchgeführt.

    a) Auf einem Odroid-C1 mit einem etwas älteren LibreElec-Fork läuft das Addon so, wie es soll - ein weiterer Hinweis darauf, dass nicht die FB oder FritzOS die Ursache sind.

    b) Ich habe auf dem Odroid-C1 das eingeschränkte Fritzbox-Konto verwendet, was kein Problem war, während das Fritzbox-Konto mit vollen Rechten auf den OSMC-basierten Geräten keine wirkliche Besserung brachte. Wenn man es allerdings schafft, einen Anruf genau in dem ersten 5-Sekunden-Fenster (also vor dem ersten Timeout) zu platzieren, wird er wie gewünscht durch das Addon signalisiert, was sich dann auch im [definition='1','2']kodi.log[/definition] entsprechend wiederfindet. Nur anschließend funktioniert es nicht mehr.

    Nach dem Ausschlussprinzip vermute ich die Ursache irgendwo bei OSMC. Eine Firewall ist dort allerdings nicht aktiv und angesichts identischer Kodi-Versionen auf Android und OSMC bin ich geneigt, den Fehler auf der Betriebsystemsebene oder ggf. bei einem Pythonmodul zu verorten. Schade, ich hatte gehofft, es wäre nur eine falsche Einstellung.

    Ich habe auch im OSMC-Forum nachgefragt,

    mal sehen, was noch passiert.

    Ich habe weiter getestet. Dazu habe ich das Addon einmal auf einem Raspi3 installiert, auf dem Kodi auf Basis von OSMC (also grob gesehen Debian) läuft und einmal auf einem Android-Tablet. Ergebnis: Auf Android läuft das Addon sofort wie gewünscht, auf OSMC (das ja auch auf der Vero4K läuft) nicht. Damit kann man zumindest schon einmal die Fritzbox/FritzOS als Fehlerquelle ausschließen. Ich schaue mal nach, ob OSMC irgendwelche Firewall-Geschichten macht, derer ich mir bislang nicht bewusst bin.

    Vielen Dank für die Antworten.

    Die IP-Adresse stimmt, mein LAN läuft schon seit Ewigkeiten als 192.168.2.0/24 und es ist i.d.R. leichter, beim Routertausch alle x Jahre dort die Einstellung zu ändern, als alle halbvergessenen Scripte etc. zu warten.

    Ich hab die Verlängerung des Timeouts gerade probiert und Kodi neu gestartet, aber das Fehlerbild ist (fast) unverändert - nur dass der Fehler jetzt 5 Sekunden später auftritt.

    grep service.fritzbox.callmonitor -i [definition='1','2']kodi.log[/definition] ergibt:

    Anschließend wiederholen sich die Fehlermeldungen. Offensichtlich findet ja zunächst ein Datenaustausch statt (die Einträge aus dem FB-Telefonbuch werden geladen), aber dann geht irgendetwas schief.

    Die Vero4K, auf der Kodi läuft, ist per LAN mit der Fritzbox verbunden, dazwischen hängt noch die CAT7a-Hausverkabelung und ein Gigabit-Switch von Netgear.

    Ich habe auch noch andere Kodi-Installationen am Start und werde es dort auch noch einmal probieren, vielleicht kann ich den Fehler eingrenzen.

    Ich befürchte, ich stehe auf dem Schlauch, denn ich bekomme das Addon (Version 3.0.10+matrix) nicht mehr zum Laufen, seit ich eine Fritzbox 7590AX mit FritzOS 7.57 am Start habe.

    Auf der Fritzbox habe ich eigens den Benutzer "kodi" mit eigenem Passwort eingerichtet und Zugriff auf "Sprachnachrichten, Faxnachrichten, FRITZ!App Fon und Anrufliste" zugelassen. Außerdem ist unter Netzwerk/Netzwerkeinstellungen der Zugriff durch Programme im LAN erlaubt. Dementsprechend sehe ich in der Ereignisanzeige der Fritzbox auch den Eintrag "Anmeldung einer App des Benutzers kodi von IP-Adresse 192.168.2.28" sobald Kodi gestartet wird. Die Aktivierung des Callmonitors über #96*5* per Telefon ist erfolgt, der ebenfalls vorhandene Callmonitor in meiner FHEM-Installation arbeitet völlig problemlos.

    Kodi läuft bei mir auf einer Vero4K mit allen aktuellen Updates.

    In [definition='1','2']kodi.log[/definition] finde ich folgende Zeilen, die sich dann fortlaufend wiederholen:

    Code
    2024-01-05 09:56:38.901 T:2959     info <general>: [service.fritzbox.callmonitor] Connected, listen to 192.168.2.1 on port 1012 
    2024-01-05 09:56:40.407 T:2959    error <general>: [service.fritzbox.callmonitor] Connection error, communication failure or other exception occured
    2024-01-05 09:56:40.407 T:2959    error <general>: [service.fritzbox.callmonitor] At line 354: timeout
    2024-01-05 09:56:40.407 T:2959    error <general>: [service.fritzbox.callmonitor] ('timed out',)

    Ich habe in den Fritzboxeinstellungen testweise auch Vollzugriff auf die Fritzbox gewährt, was aber zu keiner Veränderung geführt hat. Jetzt bin ich etwas ratlos.

    Kurzer Hinweis zu meiner VDR-Lösung:
    Bei mir hat ein "apt-get upgrade" unter Debian8 auf einem Odroid-C1 mit 2-3 Extra-Einträgen in der sources.list vorübergehend für einen "Senderausfall" gesorgt, da das Originalscript "vlc2iptv" wieder installiert wurde und damit ein Softlink auf meine angepasste Version überschrieben wurde. Etwas Grübeln und Logrecherche führte dann aber wieder zur gewünschten Funktionalität.

    OK, mit Android wird's schwierig - ohne Linux in einer chroot-Umgebung kriegst Du dort keinen VDR zum Laufen (siehe aber ganz unten!). Wie das grundsätzlich geht, habe ich vor längerer Zeit mal hier (auf Englisch) beschrieben. Da man für EWE/Zattoo keine DVB-Kernelmodule braucht, kann man auf die entsprechenden Schritte verzichten - also alle Schritte, die sich auf den Kernel/Flashen von Android etc. beziehen. Auch die Odroid-spezifischen Dinge im verlinkten Posting sind für andere Geräte nicht zutreffend. Dennoch sollte man dies ohne vernünftige Linux-Kenntnisse und Zeit zum Rumprobieren besser nicht versuchen. Ob zwingend Root-Zugriff unter Android nötig ist, weiß ich nicht genau. iirc gibt es Android-Apps, mit denen chroot-Umgebungen ohne Root möglich sind. Unter Windows könnte es in einer VM gehen, aber das ist eine ungetestete Spekulation.

    Neben einer Linux-Umgebung braucht man:

    • Kodi+IPTV-Proxy-Addon (ach...)+VDR-VNSI-Client als PVR-Addon
    • VDR+VDR-IPTV-Plugin+VDR-VNSI-Server-Plugin

    Selbstverständlich muss IPTV-Proxy mit den entsprechenden Nutzernamen und Passwörtern konfiguriert werden. Die vom IPTV-Proxy-Addon erstellte m3u-Datei braucht man als Quelle für die nötigen URLs. Das VDR-IPTV-Plugin benötigt pro Sender eine Konfigurationsdatei, die unter Debian [1] in /etc/vdr/plugins/iptv/vlcinput liegen und dem Namen des Senders in der channels.conf entsprechen muss (also ZDF.conf etc.). Diese Datei sollte folgenden Inhalt haben:

    URL="http://127.0.0.1:9001/channel.m3u8?cid=zdf&sid=ewetv"

    cid (Sender-ID) und sid (ewetv oder zattoo) müssen dann für andere Sender entsprechend angepasst werden (in jeweils eigenen conf-Dateien).
    Ferner ist pro Sender eine Zeile in der channels.conf des VDR (/var/lib/vdr/channels.conf [1]) nötig:

    ZDF;IPTV:78:S=0|P=0|F=EXT|U=vlc2iptv|A=78:I:0:256=27:257=deu@4:2321:0:28109:0:0:0

    Dabei müssen folgende Parameter angepasst werden:
    *Sendername
    *Der numerische Wert hinter IPTV: jeder Wert kann nur einmal verwendet werden, der nächste Sender bekäme also die 79 etc. Der jeweils gleiche Wert steht weiter hinten in der Zeile nochmal hinter A= (das ist aber eigentlich ein Parameter für das Script im nächsten Punkt)
    *U=vlc2iptv verweist auf das gleichnamige Script unter /usr/share/vdr/plugins/iptv [1]. Die Version, die mit dem VDR-IPTV-Plugin geliefert wird, habe ich für meine Zwecke angepasst (siehe Anhang - ACHTUNG: Die Dateiendung .txt muss vor der Verwendung entfernt werden - sie dient nur der Forumskompatibilität), da das Umkodieren nach MPEG2 bei H264 nicht nötig ist. Die Audiospur in AAC mag der VDR allerdings nicht (oder ich bin zu blöd und müsste weitere Parameter in der channels.conf anpassen, die sich mir bisher nicht erschlossen haben). Daher wird bei mir Audio on-the-fly in MP2-Audio umkodiert. Das ist in puncto CPU harmlos - es läuft bei mir auf einem Odroid-C1 (vergleichbar mit einem Raspberry PI2) und die vier Kerne haben auch während der 720p-Wiedergabe noch reichlich Reserven.
    *Wer sich auskennt, könnte auch noch weitere Parameter bearbeiten, aber das ist nicht zwingend erforderlich.

    Wem das angehängte Script und die Vielzahl an conf-Dateien nicht gefallen, kann hier nach einem anderen Lösungsansatz auf ffmpeg-Basis schauen. Dann hat der oben erwähnte Script-Parameter A=<n> auch wieder einen Sinn. Dummerweise funktioniert das dort erwähnte IP-Spoofing seit geraumer Zeit nicht mehr.
    Wenn man weitere IPTV-Sender einbinden will, brauchen die natürlich entsprechende Einträge. ARD alpha in 720p hat bei mir also eine conf Datei names ARD_alpha.conf mit dem Inhalt:
    URL="http://livestreams.br.de/i/bralpha_germ…sd=10&rebase=on"
    Natürlich braucht man auch den entsprechenden Eintrag in der channels.conf:

    ARD_alpha;IPTV:79:S=0|P=0|F=EXT|U=vlc2iptv|A=79:I:0:256=27:257=deu@4:2321:0:28109:0:0:0

    Unter Kodi muss man dann das VDR VNSI Client Addon aktivieren und konfigurieren. Senderlogos können am einfachsten in einem lokalen Ordner abgelegt werden (Einstellungen > TV > Menü/OSD > Ordner mit Kanalsymbolen). Das EPG holt Kodi sich dann vom VDR - sofern dieser eines hat. Meine oben erwähnte Script-Lösung für's EPG werde ich zunächst ganz bewusst nicht posten, da sie:
    a) sehr lahm ist, teilweise noch recht hakelig läuft und ich nicht verantwortlich für Probleme auf Euren Rechnern sein möchte.
    b) noch nicht vollständig ist, denn ich habe für manche Sender noch keine XMLTV-Quellen gefunden.
    c) eine zusätzliche DVB-Quelle für den VDR zwar nicht zwingend benötigt, aber in der gegenwärtigen Form verwendet, um die Geschichte zu beschleunigen. Das geht aber am Punkt IPTV vorbei.
    Ich werde zwar schauen, ob ich das noch verbessern kann, aber ich wäre meinerseits für Hinweise in Sachen XMLTV-EPG für die privaten und internationalen Sender bei EWE-TV bzw. Zattoo dankbar. (Ja, ich weiß, dass es ein VDR-XMLTV-Plugin gibt, aber mir sind bisher genau zwei Linux-Programme begegnet, die ich einfach nicht verstehe/verstehen will: jenes Plugin und vi)

    Ich habe noch nicht probiert, das IPTV-Proxy-Addon selbst von 127.0.0.1 auf die Adresse im lokalen LAN zu verändern, die hier beschriebene Lösung funktioniert aber dank VDR-VNSI-Server bei korrekter Konfiguration auch als Backend für andere Rechner im LAN. Anders ausgedrückt: Ein RPi2 o.ä. mit den beschriebenen Software-Komponenten kann neben dem DSL-Router "geparkt" werden und als PVR-Backend (sowie ggf. als Kodi-UPnP-Sever) für das ganze LAN genutzt werden. Dann brauchen auch Android- und Windows-User keine Verrenkungen mehr.

    [1] Die Pfade unter Debian-basierten Distros weichen immer wieder mal von denen ab, die man laut VDR-Dokumentation erwarten sollte - das nervt manchmal.

    Das ist ein hübscher Nebeneffekt meiner Lösung mit dem VDR: Ich kann nicht nur aufnehmen, sondern zumindest das sichtbare Ruckeln ist weg. Ein Druck auf "o" zeigt dann zwar immer noch geskippte Frames, aber ganz offensichtlich kommt mein Backend besser damit klar. Insbesondere bin ich die (für mich) extrem lästigen Audio-Glitches los. Vorher (also mit dem IPTV Simple Addon) hatte ich auch Probleme mit den HD-Sendern.
    Hinsichtlich des EPGs habe ich eine vorläufige Lösung, die per Skript z.T. auf XMLTV (tv_grab_eu_egon) und teilweise auf dem Kopieren von Daten der DVB-T-Sender beruht, aber das ist noch ausbaufähig Eurospot, DMAX und Konsorten fehlen mir noch).

    Erstmal: Vielen Dank für das Addon. Es funktioniert übrigens auch für swb TV, also den Bremer Ableger der EWE.

    Zusätzlich habe ich für mich eine etwas andere Nutzungsvariante gefunden, als im OP beschrieben:
    Da ich als PVR-Backend für klassisches TV den VDR nutze, habe ich das VDR-IPTV-Plugin installiert und die gewünschten swbTV-/Zattoo-Sender per IPTV-Proxy eingebunden. Falls Interesse besteht, kann ich das auch detailliert beschreiben.

    Erstmal vielen Dank für die Mühe. Das meiste scheint gut zu laufen, allerdings habe ich eben bim Öffnen des "Fast N Loud"-Ordners einen Scriptfehler bekommen.
    Schuss ins Blaue (ohne es geprüft zu haben): Da sind '-Zeichen im Titel und die sorgen im Script für Ärger. Ich schau mal, ob ich etwas Brauchbares im Log finde. (Geht grade noch nicht, XBMC ist in Benutzung und unter Android habe ich keinen ssh-Zugriff).

    Thomas