Tastenzuordnung für Fernbedienung in Kodi 18 stimmt nicht mehr

  • Hi,


    ich hatte gerade ein Update auf das neue Kodi 18 gemacht. Das Funktioniert auch soweit ganz gut (incl. Passthrough). Leider gehen nun bei meiner Fernbedienung nicht mehr alle Tasten. Also es gehen nur noch die Pfeile und die Lautstärketasten. Auf alle anderen reagiert Kodi nicht mehr.

    Hat jemand eine Idee, wie man die Tastenzuordnung wieder korrekt zuordnen kann?


    Grüße

    Frank

  • Ich habe die Lösung dafür auf Wiki Ubuntuusers gefunden.

    Das Problem besteht darin, dass die Programme irw und irexec auf die Datei /var/run/lirc/lircd zugreifen, welche nicht mehr angelegt wird. Der Paket-Maintainer hat das Standard-Socket von /var/run/lirc/lircd nach /dev/lircd verlegt, die Programme irw und irexec jedoch bisher nicht angepasst 🇬🇧. Auch das Verzeichnis /var/run/lirc/ existiert dann i.d.R. nicht.

    Das Verzeichnis und der Link auf das richtige Socket müssen dann angelegt werden.

    Also jetzt geht bei mir wieder alles.

  • Hallo Frank, kannst du mir bitte in kurzen Worten beschreiben, wie die Umkonfiguration durchzuführen ist.

    Danke

  • Zum Testen kannst du die folgenden Befehle im Terminal verwenden:

    Code
    sudo mkdir -p /var/run/lirc
    sudo ln -s /dev/lircd /var/run/lirc/lircd 

    Diese überleben aber nicht einen Neustart der Linux Station dafür muss die folgende Zeile in der Datei /etc/rc.local eingefügt werden:

    Code
    mkdir -p /var/run/lirc/ && ln -s /dev/lircd /var/run/lirc/lircd
  • dafür muss die folgende Zeile in der Datei /etc/rc.local eingefügt werden

    Auch wenn das Verfahren so funktionieren mag, ist das nicht die "saubere" Variante. Zum einen, weil Ubuntu mittlerweile auch Systemd einsetzt und zum anderen weil es quatsch ist, jedes mal dieses Verzeichnis anzulegen.


    Variante 1:

    Erstelle für das durchzuführende Verhalten eine systemd unit. Ist auch nicht viel komplizierter, als der Eintrag in der rc.local und wird beispielsweise im Ubuntuusers Wiki erklärt: https://wiki.ubuntuusers.de/systemd/Units/

    Variante 2:

    Lege das Verzeichnis auf dem Host, sprich dem NAS selbst an und mounte es per lxc.mount.entry an die entsprechende Stelle der Linux Station. In der Datei /share/CACHEDEV1_DATA/.qpkg/ubuntu-hd/lxc/ubuntu_1604/config sind bereits zahlreiche mounts eingetragen, du brauchst also nur die entsprechende Zeile kopieren und die Pfade anzupassen.

  • tuxflo

    Leider kenne ich mich mit Linux nur rudimentär aus. So richtig habe ich die beiden Varianten noch nicht verstanden. Lege ich dann z.B. mit der Unitdatei den Symlink an und wo kommt die Datei hin? Was sind eigentlich die Vorteile der "sauberen" Varianten.


    dr_mike

    Meine Systemplatte ist eine SSD, dass sollte erstmal nicht groß stören. Warum eingentlich?


    @all

    Ursprünglich sollte es auch mit einer Umgebungsvariable (LIRC_SOCKET_PATH) gehen. Scheinbar geht die erst in moderneren Linuxversionen.

  • dr_mike Wie kommst du auf diese Vermutung? Ob das Verzeichnis im Container oder auf dem Host liegt macht was die Stromsparmechanismen oder Ruhezeiten keinen Unterschied.


    SirBoss Wenn deine Kenntnisse nur "rudimentär" sind, dann kannst du es auch so lassen ;)
    Ich wollte nur darauf hinaus, dass das beschriebene Vorgehen mit der rc.local heutzutage keine "best practice" mehr ist. Dieses Vorgehen stammt noch aus der Zeit, als systemd noch nicht eingeführt wurde und geht von einer linearen Abarbeitung der zu startenden Prozesse aus. Demnach hast du keine wirklichen "Vorteile" außer das sich das System ggf. besser um den Dienst kümmern kann und er z.B. in der Ausgabe von systemctl status mit aufgelistet wird. Bei einer Sache wie einem einfachen Verzeichnis ist das aber vermutlich egal. Interessant wird es, falls du mal auf eine neuere Ubuntu Version updaten bzw. Upgraden möchtest, denn ich meine in Version 18.0X aufwärts ist die rc.local standardmäßig deaktiviert (gefährliches Halbwissen)

  • tuxflo

    Bin mir nicht 100% sicher aber...

    Auf embedded Systemen liegen die Verzeichnisse /tmp, /var, /proc und /sys normalerweise im temp-Filesystem im RAM und werden zur Laufzeit erstellt und befüllt. Somit ist kein Plattenzugriff notwendig. Wenn man nun auf ein Verzeichnis auf einer Platte mountet wird ein Plattenzugriff notwendig, wenn auf Inhalte dieses Mounts zugegriffen wird.


    Wie sieht denn die Ausgabe von cat /proc/mounts in so einem modifizierten Container aus?

  • Ok, das klingt in der Tat einleuchtend wobei ich mir da trotzdem nicht ganz sicher bin. Die Ausgabe von /proc/mounts wird dir innerhalb des Containers nicht so viel bringen, da der ja nur das anzeigt, was er "gesagt" bekommt. Da ist das entsprechende config File schon aufschlussreicher:

    Wie man sieht sind in der Tat die Verzeichnisse /sys und /var auf die entsprechenden Ordner des Host Systems gelegt. Aber dann frage ich mich trotzdem wie das funktionieren soll, denn gerade auf Maschinen mit recht wenig RAM läuft das doch super schnell voll. Wenn z.B. alle Logs des Hosts und alle der Container (sowohl LXC als auch Docker) nach /var schreiben und das wiederum nur im RAM des Hosts liegt, dann kann ich mir nicht vorstellen das man so ein System mit 4GB oder 8GM RAM betreiben kann.

  • Logs sollten auch nicht unbegrenzt fortgeschrieben sondern sinnvoll begrenzt werden. Dafür gibts das Logrotate. Dann belegen Logs nicht Unmengen an Speicher.

  • Ich habe ja auch nichts von "unbegrenzt" geschrieben aber wenn man mal mehrere Container laufen lässt kann sich das je nach Art der Container dennoch schnell häufen.
    Wenn es wirklich so wäre, dass die Sachen ausschließlich im RAM landen sieht es nach einem Stromausfall (ohne USV) auch eher schlecht mit den Log-Daten aus.