keine Verbindung mit dem ioBroker kodi addon

  • Hallo Forum,
    ich habe folgendes Problem:
    Seit ich auf die [definition='2','1']advancedsettings[/definition].xml umgestellt habe, bekomme ich mit dem ioBroker addon keine Verbindung mehr zu meinen kodi-Geräten.

    Folgende Geräte/ Installationen habe ich im Einsatz:
    1x kodi-headless docker container mit [definition='2','1']advancedsettings[/definition].xml
    1x LibreELEC auf RPi4 mit [definition='2','1']advancedsettings[/definition].xml

    1x LibreELEC auf RPi3b+ klassisch

    Lt. Entwickler des ioBroker addon liefert meine Websocketverbindung zu Binary-Content anstalle von JSON.

    Ich kann das klassisch installierte LibreELEC per ioBroker steuern.
    Aber zu den beiden anderen Installationen, die ich per [definition='2','1']advancedsettings[/definition].xml konfiguriert habe, bekomme ich keine Verbindung.

    Könnte ich in der [definition='2','1']advancedsettings[/definition].xml einen Fehler haben oder etwas nicht oder falsch konfiguriert haben?
    Hier meine [definition='2','1']advancedsettings[/definition].xml:

    Oder liege ich mit meiner Vermutung falsch und es hat einen anderen Grund?

  • Nimm einfach mal alles aus der Advancedsettings raus und versuch es mal ohne. Dann nimmst du nach und nach wieder die Dinge rein, die du drin hast und testest jedes Mal. Wenn es dann nach einem geänderten Eintrag nicht mehr geht, hast du das Problem ganz allein identifiziert.

    Wenn ich mal so durch deine [definition='2','1']advancedsettings[/definition] durch gehe, sehe ich da einige Einträge, die es gar nicht gibt. Oder ich habs übersehen.

    Sowas wie "nodvdrom" finde ich zum Beispiel nicht

    Oder auch "enablemouse"

    Einfach mal hier nach dem Setting suchen: https://github.com/xbmc/xbmc/blob…cedSettings.cpp

    Und dann alles raus werfen, was es nicht mehr gibt.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • @DaVu danke für deinen Tipp.
    Ich habe jetzt bei dem RPi4 mit LibreELEC die [definition='2','1']advancedsettings[/definition].xml komplett gekürzt:

    Darauf hin sind (wie zu erwarten war) viele Einträge im Konfigurationsmenü wieder aufgetaucht.
    Direkt nach dem Neustart konnte ich immer noch keine Verbindung herstellen.
    Um die JSON-RCP API zu aktivieren muss ich ja unter Einstellungen/ Dienste/ Anwendungssteuerung beide Zeilen aktivieren.
    Erst nach dem deaktivieren und wieder aktivieren konnte das ioBroker-Addon die Verbindung herstellen.

    Allerdings musste ich nach dem aktivieren der "Fernsteuerung durch auf anderen Systemen befindliche Anwendungen zulassen" ein zusätzliches Warnungsfenster bestätigen. Könnte hier mein Problem entstehen? Dass die Advancedsettings.xml die Warnung nicht bestätigen können? Habt Ihr eine Idee, ob ich irgendwo in den Systemdateien bei der Warnung aus einem "false" ein "true" machen kann?

    Denn bei dem docker-Headless habe ich keine Benutzeroberfläche außer Chorus2.

  • Ich habe mir die guisettings.xml in Bezug auf diese Settings nicht angesehen. Das war nur ein Schuss ins Blaue.

    Eine andere Idee habe ich nicht.

    Da gibt es halt auch den ein oder anderen Fallstrick in Bezug auf Container. Wenn du das persistent haben möchtest musst du das ohnehin als Volume verfügbar machen. Ansonsten ist das nach nem Container-Neustart wieder weg. Da weiß ich halt nicht wie der Container grundsätzlich aufgebaut ist.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • So...

    Ich habe gerade nochmal rein geschaut.

    Code
    <setting id="services.webserverpassword">1234</setting>
    <setting id="services.webserver">true</setting>
    <setting id="services.esallinterfaces">true</setting>

    Das sind die benötigten Settings, die man über die guisettings.xml ändern muss. Aber....gerade services.webserver bzw. services.esallinterfaces lassen sich nicht ohne die Bestätigung der Warnmeldung aktivieren. Ich habe mal im Code geschaut und man kann das ganze nicht über eine [definition='2','1']advancedsettings[/definition] unterbinden.

    Wenn ich am Wochenende Zeit habe, versuche ich mal ein advancedsetting dafür zu erstellen. Ich kann mir aber gut vorstellen, dass das aus Sicherheitsgründen vielleicht vom Team abgelehnt wird.

    Aktuell ist es so, dass man nur über eine Bestätigung des Users über die GUI diese Dienste, die zur Steuerung von anderen Systemen aus dienen, aktivieren kann. Gibt es ein advancedsetting dafür, dann kann ein potentieller Angreifer über diese Option und wenn er auf anderem Wege an diese Datei kommt, die Steuerung aktivieren ohne, dass es der User mitbekommt. Da könnte ich mir gut vorstellen, dass genau das nicht der Fall sein sollte.

    Ich werde aber das "Headless"-Argument einbringen und dass es Usern so nicht möglich ist, diese Option nutzen zu können, wenn kein Bildschirm angeschlossen ist und man einen Headless Docker verwendet.

    Wenn es akzeptiert wird, dann könnte ich mir weiter vorstellen, dass es maximal für Kodi 21 kommt. Einen (etwas) ungetesteten Backport dieser Option würde ich so nicht riskieren wollen, da ich nicht weiß, wie es sich auf bestehende Einstellungen auswirken könnte. Nicht, dass es dann noch zu einem "Breaking Change" entwickelt.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

  • @DaVu Danke für deine Hilfe.
    Tatsächlich verstehe ich Abfrage bzw. Bestätigung per UI.

    Mir ist klar, dass KODI nicht für den headless-Einsatz programmiert wurde und dass ich mit dem Einsatz so ziemlich einsam auf weiter Flur stehe. Aber ich finde, die Software hat Potential dieser Funktion gerecht zu werden. Und eine Konfiguration per Advancedsettings.xml wäre eine gute Sache.

    Auf lange Sicht wäre es natürlich grandios, wenn sich mehr Anwender für einen Headless-Server interessieren würden und dadurch evtl. eine komplette Konfiguration per Chorus2 ermöglicht würde.

  • dafür ist Kodi einfach nicht gemacht. warum nimmt man nicht ein Backend wie jellyfin / emby oder Plex. die haben dann auch deine Konfiguration komplett per webgui.

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

  • Ich finde die Entwicklung des Headless-Docker toll und je mehr sich damit beschäftigen, desto bessere Ideen gibt es das weiter voran zu treiben.

    Meine Idee über die [definition='2','1']advancedsettings[/definition] ist ja nur eine und aus Entwicklersicht ggf. auch stümperhaft. Liegt halt daran, dass ich kein Entwickler bin. Aber ich stimme @Captain Blackbeard zu. Wenn sich mehr damit beschäftigen würden, dann gäbe es vielleicht bessere Lösungen.

    Natürlich gibt es andere Syssteme, die das schon können. Wenn man sich aber immer nur in seiner Komfortzone oder im "das kenne ich"-Dunstkreis bewegt, geht es nie weiter.

    Und eines ist mal sicher: "Stillstand ist Rückschritt"

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!