Der Martin: lirc auf Linux Mint 18.2 installieren schägt fehl

Hallo alle miteinander,

vor kurzem habe ich bei einem Elektronik-Discounter aus einer Laune heraus zwei Sets mit einer MCE-Fernbedienung und dem zugehörigen USB-Empfänger bestellt. Zum Spielen und Experimentieren, und wenn's dann funktioniert, dann auch für meinen Multimedia-PC. Zum Testen und Experimentieren darf aber erstmal mein Desktop-Rechner herhalten.

Aber ich scheitere schon bei den Vorbereitungen. Unter Linux wäre lirc wohl die typische Software, um nach einer Fernbedienung zu lauschen und den Tasten dann bestimmte Funktionen bzw. Programmaufrufe zuzuordnen. Und ich bekomme lirc auf meinem Desktop-PC nicht installiert. Nachfolgend zur Information die Ausgabe beim Versuch, lirc mit apt bzw. apt-get zu installieren:

# apt-get install lirc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libftdi1 setserial
Suggested packages:
  lirc-x
The following NEW packages will be installed:
  libftdi1 lirc setserial
0 upgraded, 3 newly installed, 0 to remove and 23 not upgraded.
Need to get 0 B/428 kB of archives.
After this operation, 2 341 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
Selecting previously unselected package libftdi1:amd64.
(Reading database ... 250558 files and directories currently installed.)
Preparing to unpack .../libftdi1_0.20-4build1_amd64.deb ...
Unpacking libftdi1:amd64 (0.20-4build1) ...
Selecting previously unselected package setserial.
Preparing to unpack .../setserial_2.17-49_amd64.deb ...
Unpacking setserial (2.17-49) ...
Selecting previously unselected package lirc.
Preparing to unpack .../lirc_0.9.0-0ubuntu6_amd64.deb ...
Unpacking lirc (0.9.0-0ubuntu6) ...
Processing triggers for libc-bin (2.23-0ubuntu11) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu21.27) ...
Processing triggers for ureadahead (0.100.0-19.1) ...
Processing triggers for doc-base (0.10.7) ...
Processing 1 added doc-base file...
Registering documents with scrollkeeper...
Setting up libftdi1:amd64 (0.20-4build1) ...
Setting up setserial (2.17-49) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Setting up lirc (0.9.0-0ubuntu6) ...

An dieser Stelle poppt ein ncurses-basiertes Konfigurationstool auf, das von mir wissen möchte, was für eine Fernbedienung (und optional, was für einen IR-Transmitter) ich verwende. Ich wähle "Windows Media Center USB Remote" und "None" aus, das Konfigurationstool verschwindet wieder, und dann passiert ungefähr fünf Minuten gar nichts. Dann geht's weiter:

Job for lirc.service failed because a timeout was exceeded. See "systemctl status lirc.service" and "journalctl -xe" for details.
invoke-rc.d: initscript lirc, action "start" failed.
● lirc.service - LSB: Starts LIRC daemon.
   Loaded: loaded (/etc/init.d/lirc; bad; vendor preset: enabled)
   Active: failed (Result: timeout) since Sa 2020-05-16 14:59:29 CEST; 18ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 19554 ExecStart=/etc/init.d/lirc start (code=killed, signal=TERM)
   CGroup: /system.slice/lirc.service
           ├─12566 modprobe mceusb
           ├─12759 modprobe mceusb
           ├─14539 modprobe mceusb
           ├─14728 modprobe mceusb
           ├─14964 modprobe mceusb
           └─19561 modprobe mceusb

May 16 14:54:29 systemd[1]: Starting LSB: Starts LIRC daemon....
May 16 14:54:29 lirc[19554]:  * Loading LIRC modules
May 16 14:59:29 systemd[1]: lirc.service: Start operation timed out. ...g.
May 16 14:59:29 systemd[1]: Failed to start LSB: Starts LIRC daemon..
May 16 14:59:29 systemd[1]: lirc.service: Unit entered failed state.
May 16 14:59:29 systemd[1]: lirc.service: Failed with result 'timeout'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package lirc (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.23-0ubuntu11) ...
Processing triggers for systemd (229-4ubuntu21.27) ...
Processing triggers for ureadahead (0.100.0-19.1) ...
Errors were encountered while processing:
 lirc
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ich habe gestern schon den halben Tag mit Internet-Recherche zu diesem Problem verbracht, habe aber nur eine Menge Hinweise gefunden, die meinem Problem ähneln, aber für andere Versionen gelten. Die lirc-Version, die mit Ubuntu 18.04 kommt (lirc 0.10.irgendwas), hat da wohl ein ernstes Problem, das Ubuntu aber schon von Debian geerbt hat. Auf debian.org habe ich einen entsprechenden Bug-Report und einen Workaround gefunden, der letzte Eintrag dazu ist noch von Mai 2020, also taufrisch.

Ich verwende aber noch Linux Mint 18.2, das auf Ubuntu 16.04 basiert, und die lirc-Version im zugehörigen Repo ist 0.9.x, bei der solche Probleme anscheinend noch nicht bekannt sind.

Wo kann ich jetzt noch ansetzen, um mein Problem einzugrenzen und bestenfalls zu lösen? Oh, die beiden Ratschläge in der oben zitierten Ausgabe haben mich nicht weitergebracht. systemctl status lirc.service murmelt was von loaded, aber failed. Das ist nicht informativ. Die Ausgabe von journalctl -xe zeigt mir gar nichts, was ich irgendwie mit lirc in Verbindung bringen kann.

Mittlerweile habe ich lirc wieder ge"purge"t, um das System sauber zu halten. Aber wenn ich einen vielversprechenden Hinweis bekomme, probier ichs gern nochmal.

Live long and pros healthy,
 Martin

--
Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
  1. Hey,

    sieht für mich aus als würde das kernelmodul nicht laden. Unabhängig von dem lirc daemon, würde ich erstmal da ansetzen.

    Ich hab hier immernoch nen seriellen DIY empfänger rumliegen, hab irgendwann in der 90ern mal damit gespielt. War lustig.

    -- /entropie

    --
    Whenever people agree with me I always feel I must be wrong. -- Oscar Wilde
    1. Hallo,

      ich bin ja gerührt, dass doch noch jemand ein paar tröstende Worte findet. ;-)

      sieht für mich aus als würde das kernelmodul nicht laden.

      ich weiß nicht genau, welches Kernelmodul du meinst, AFAIK ist die Unterstützung für IR-Geräte doch schon im Kernel integriert. Anyway, die Ausgabe von cat /proc/bus/input/devices zeigt mir unter anderem das da:

      I: Bus=0003 Vendor=0471 Product=0613 Version=0101
      N: Name="Media Center Ed. eHome Infrared Remote Transceiver (0471:0613)"
      P: Phys=usb-0000:00:12.2-1.1
      S: Sysfs=/devices/pci0000:00/0000:00:12.2/usb1/1-1/1-1.1/1-1.1:1.0/rc/rc0/input10
      U: Uniq=
      H: Handlers=kbd event9 
      B: PROP=0
      B: EV=100013
      B: KEY=fff 0 200108fc32e 237605100000000 0 700158000 419200004001 8e968000000000 10000000
      B: MSC=10
      

      Das zeigt mir, dass das Gerät schon mal vom Kernel erkannt und richtig eingeordnet worden ist.

      Ich hab hier immernoch nen seriellen DIY empfänger rumliegen, hab irgendwann in der 90ern mal damit gespielt. War lustig.

      Dunkel erinnere ich mich auch an solche Experimente. Ich glaube, das war bei mir noch unter Windows 98. Da hat man sich zunutze gemacht, dass man die handelsübliche Sellerie-Schnittstelle auf 115200bps einstellen kann, was so etwa das Dreifache der bei Fernbedieungen üblichen Modulationsfrequenz von 38kHz ist. So konnte man das Signal mit wenig "Intelligenz" in Hardware abtasten.

      Live long and pros healthy,
       Martin

      --
      Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
  2. Ich dachte der timeout käme von laden des modules (mceusb). Wenn nicht, daemon manuell starten (gug in die lirc.service file von systemd um die exakten parameter zu bekommen) und rausfinden was der eigentliche fehler ist. Das ist ja scheinbar nicht offensichtlich.

    Edit: hab ich auf den falschen beitrag geantwortet? Komisch, kann wohl das forum nicht mehr bedienen.

    -- /entropie

    --
    Whenever people agree with me I always feel I must be wrong. -- Oscar Wilde
    1. Hallo,

      Ich dachte der timeout käme von laden des modules (mceusb).

      guter Verdacht, danke. Ich habe das eben nochmal versucht nachzuvollziehen: modprobe mceusb einzeln in einem root-Terminal eingegeben. Das hängt dann bis in alle Ewigkeit (oder bis zu einem gewlatsamen kill). Aber was mache ich jetzt aus dieser Erkenntnis?

      Wenn nicht, daemon manuell starten

      Und wenn doch ...?

      Edit: hab ich auf den falschen beitrag geantwortet? Komisch, kann wohl das forum nicht mehr bedienen.

      Macht nix, du warst ja auch eine Weile weg!

      Live long and pros healthy,
       Martin

      --
      Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
      1. Hallo,

        Aber was mache ich jetzt aus dieser Erkenntnis?

        Jetzt geht der spass los. Ich geb dir mal paar ansätze wie ich starten würde:

        • ausführliches googeln (modprobe, mcusb, timeouts), lirc würde ich erstmal aussen vor lassen. versuch aktuelle ergebnisse zu bekommen.

        • kernel upgraden

        • down/upgrade des lirc programms

        • (bzw. verschiedene kombinationen der oberen beide punkte ausprobieren)

        Ich hab gerade ein bisschen gesucht. Kann es sein das es auch noch ein anderes paket gibt?

        inputlirc

        -- /entropie

        --
        Whenever people agree with me I always feel I must be wrong. -- Oscar Wilde