[Gelöst] yavdr ansible - "mplay2"-Fernbedienung funktioniert nicht

  • Hallo zusammen,


    nach der Neuinstallation von yaVDR ansible bekomme ich meine Fernbedienung nicht mehr zum laufen. Unter yaVDR 0.6 funktionierte sie problemlos.

    Dabei wurde lirc mit dem Treiber mplay2 verwendet.


    Es handelt sich um einen Empfänger der in einem Moncaso 312 Gehäuse verbaut ist und über USB angeschlossen ist.

    lsusb zeigt ihn wie folgt:

    Code
    1. Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

    Das Gerät wird beim Start automatisch erkannt und und vom Kernel Modul ftdi_sio das Device

    Code
    1. crw-rw---- 1 root dialout 188, 0 Nov 15 15:16 /dev/ttyUSB0

    angelegt.

    dmesg sagt dazu:


    Das seltsame ist, dass noch nicht einmal mit cat /dev/ttyUSB0 irgendwas ausgegeben wird wenn man eine Taste auf der Bedienung drückt. Dementsprechend zeigen mode2 und irw auch nichts an.


    Aktuell verwende ich die Kernel Version 4.15.0-70-generic.


    Ich bin echt ratlos und für jede Hilfe oder Idee dankbar!

    Falls ihr noch irgendwelche Infos braucht, lasst es mit bitte wissen.


    LÖSUNG:

    Ursache war ein Fehler in lirc (Datei: mplay.c).

    seahawk1986 hat diesen Fehler in der lirc Paketversion 0.10.1-8yavdr0~bionic behoben.


    (Da das Thema aus yaVDR Sicht erledigt ist, setze ich diesen Thread auf "Gelöst")

    The post was edited 1 time, last by lorweb: Lösung hinzugefügt ().

  • Wie genau hast du die Lirc-Konfiguration angepasst?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wie genau hast du die Lirc-Konfiguration angepasst?

    ich habe mir gleich eine eigene "Rolle" für ansible erstellt indem ich die vorhandene autoinstall-atric-usb kopiert und wie folgt angepasst habe:

    - die Installation von lirc-drv-irman entfernt

    - die USB ID "04d8:f844" durch "0403:6001" ersetzt.

    - und im Template entsprechend driver und device angepasst.


    Die Rolle habe ich dann in der yavdr07.yml ergänzt. Sie ließ sich dann auch ausführen und hat eigentlich alles wie erwartet durchgeführt. Der lircd Service wird auch gestartet. Für mein dafürhalten sie der Log auch recht gut aus:


    Zusätzlich habe ich noch die vorhandene Konfiguration der Fernbedienung unter /etc/lirc/lircd.conf.d/moncaso_312.lircd.conf abgelegt.


    Meintest du das? Oder soll ich noch irgendwelche Dateien posten?

  • Vermutlich tut sich beim Anlernen mit irrecord auch nichts, oder? sudo irrecord -H mplay2 -d /dev/ttyUSB0 test.conf


    Bei der MLD gab vor zwei Jahren auch schon mal eine Meldung zu solchen Problemen mit dem Empfänger, leider ist das ergebnislos verlaufen: https://www.minidvblinux.de/forum/index.php?topic=8713.0


    Könntest du mal versuchen lircd mit maximalem Loglevel (loglevel = 10 in der lirc_options.conf im Abschnitt [lircd]) starten zu lassen? Da sieht man hoffentlich besser, wie weit er bei der Initalisierung kommt und was danach passiert. Außerdem würde ich mal versuchen ,nowheel an den Gerätepfad anzuhängen, um zu sehen, ob da etwas mit dem Threading nicht klappt (wegen dem Kommentar in https://sourceforge.net/p/lirc…tree/plugins/mplay.c#l666).


    Das seltsame ist, dass noch nicht einmal mit cat /dev/ttyUSB0 irgendwas ausgegeben wird wenn man eine Taste auf der Bedienung drückt.

    Soweit ich das dem Treiber entnehmen kann, muss man erst das Byte 0x96 an das Gerät schicken und eine Baud-Rate von 57600 nutzen, damit der Empfänger Daten sendet - falls bei den oben genannten Dingen keine zielführenden Hinweise kommen, stoppe bitte mal lircd und probiere folgendes:

    Code
    1. sudo apt install python3-pyserial

    Und dann mal dieses Skript mit root-Rechten ausführen und schauen, ob der Empfänger darauf hin etwas sendet, wenn man Tasten drückt:

    Code
    1. #!/usr/bin/env python3
    2. import serial
    3. with serial.Serial('/dev/ttyUSB0', 57600, timeout=1) as ser:
    4. ser.write(0x96)
    5. while True:
    6. buffer = ser.read()
    7. if buffer:
    8. print(buffer)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Was sagt evtest am passenden Gerät (vorher ev. eventlircd stoppen)?


    Ansonsten tut sich nichts mehr. Auch nicht, wenn ich eine Taste drücke.


    Mich verwirrt ja immer noch, dass sudo cat /dev/ttyUSB0 nichts ausgibt (also wenn lircd gestoppt ist). Von daher denke ich, dass das Problem schon auf unterster Ebene ist. Oder liege ich da falsch?


    EDIT: ... ich liege falsch! :) @seahawk1986: habe deinen Beitrag erst danach gesehen.

  • Mich verwirrt ja immer noch, dass sudo cat /dev/ttyUSB0 nichts ausgibt (also wenn lircd gestoppt ist). Von daher denke ich, dass das Problem schon auf unterster Ebene ist. Oder liege ich da falsch?

    Der Treiber scheint erst ein Byte 0x96 an das Gerät zu senden, bevor er davon lesen kann (vgl. mein voriger Post: ansible - "mplay2"-Fernbedienung funktioniert nicht) - eigentlich müsste lircd Fehler werfen, wenn das nicht klappt, aber vielleicht sieht man mit mehr Debug-Ausgaben mehr.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • @seahawk1986


    Richtig, sudo irrecord -H mplay2 -d /dev/ttyUSB0 test.conf empfängt nichts und bricht dann nach einem Timeout ab.


    (den MLD Thread hatte ich auch schon gefunden)


    Hier die Ausgabe von sudo lircd -H mplay2 -d /dev/ttyUSB0,nowheel -n -D10


    Dein Python Skript hat leider auch nichts ausgegeben (bei gestoppten lircd).


    (Ich muss schon sagen, entweder du steckst recht tief in der Materie oder du bist verdammt schnell!!! oder beides:))

    Schon mal vielen Dank für deine sehr schnellen und guten Beiträge!!!

  • Kannst du mal nachsehen, ob du etwas mit cat, screen (damit kann man auch die Baudrate setzen) oder meinem Python-Skript von dem ttyUSB-Gerät lesen kannst, nachdem es stromlos war und noch nicht von lircd initialisiert wurde?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Findet sich ein "Entering mplayfamily_listen()" in der Ausgabe von Lirc mit Loglevel 10, wenn du es ohne an den Device-Pfad angehängtes ,nowheel startest?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • So, jetzt hatte ich wieder etwas Zeit zum Testen.

    Folgende Erkenntnis:

    • das loglevel in der /etc/lirc/lirc_options.conf scheint ignoriert zu werden, darum habe ich lircd manuell gestartet.
    • Im C-File habe ich gesehen, dass der Treiber erst geladen wird, wenn sich ein Client anmeldet. Darum habe ich immer anschließend irw gestartet.

    Nimmt man beides zusammen, sieht man auch die einzelnen Traces im Log :)

    Mit und ohne ,nowheel kommt das "Entering mplayfamily_listen()"!

    Nur die beiden untersten Zeilen (siehe unten) unterscheiden sich. Aber das muss ich dir sicher nicht sagen...:)

    Code
    1. Nov 16 18:19:29.985251 vdr lircd: Notice: lircd(mplay2) ready, using /var/run/lirc/lircd0
    2. Nov 16 18:19:41.390689 vdr lircd: Trace: registering local client
    3. Nov 16 18:19:41.390810 vdr lircd: Notice: accepted new client on /var/run/lirc/lircd0
    4. Nov 16 18:19:41.390858 vdr lircd: Trace: Entering mplay2_init()
    5. Nov 16 18:19:41.390873 vdr lircd: Trace: Entering mplayfamily_init()
    6. Nov 16 18:19:41.390888 vdr lircd: Trace: Device string '/dev/ttyUSB0,nowheel'
    7. Nov 16 18:19:41.390934 vdr lircd: Trace: Found option string 'nowheel'
    8. Nov 16 18:19:41.390948 vdr lircd: Trace: Using device path '/dev/ttyUSB0' (wheel disabled state is 1)


    Deinen anderen Test werde ich noch durchführen und ansonsten mal versuchen anhand des C-Files weiter zu kommen.

    Danke für den Verweis!

    (Nur zur Info: übrigens verwende ich bzw. wir(?) die Version 0.10 nicht 0.9 wie in deinem Link - ich weiß allerdings nicht, ob sich diese unterscheiden)

  • Kannst du mal nachsehen, ob du etwas mit cat, screen (damit kann man auch die Baudrate setzen) oder meinem Python-Skript von dem ttyUSB-Gerät lesen kannst, nachdem es stromlos war und noch nicht von lircd initialisiert wurde?

    So den Test habe ich nun auch durchgeführt. Leider wieder keine Ausgabe.


    Ich muss dazu sagen, dass ich der Einfachheit halber einfach die /usr/sbin/lircd umbenannt und dann den Rechner neu gestartet habe (er war zwischendurch komplett Stromlos). Ist vielleicht nicht die eleganteste Lösung aber es schien mir die schnellste.

  • ... könnte das Problem mit dem Eintrag Debug: No systemd fd found im Log zusammenhängen?

    EDIT:

    Nein, vermutlich nicht, weiter unten kommt ja Trace: started server socket...

  • ich denke, ich habe das Problem gefunden. Wie es für mich aussieht ist ein Fehler beim Mergen in die mplay.c gekommen.

    Siehe diff hier:

    https://sourceforge.net/p/lirc…f20d609a62ae9fd9510307b5c

    (ich hoffe der Link funktioniert)


    wenn ich die alte "else if" Bedingung wieder einfüge, funktioniert zumindest mode2 wieder. Den Rest habe ich noch nicht getestet.

  • Der Control-Flow ist da in der Tat durcheinander gekommen, ich weiß aber nicht, ob das davor wirklich besser war... Die Intention ist ja im Fehlerfall die restlichen Schritte zu überspringen - das ist einer der Fälle, in denen eine Fehlerbehandlung mit goto IMHO deutlich einfacher und übersichtlicher funktioniert... - ich lasse gerade lircd mit einem Patch bauen, probier mal bitte, ob das für dich funktioniert.


    Kann mir bitte noch einer einen Tipp geben, wie ich lirc übersetzten muss, um die aktuelle lirc Installation komplett zu ersetzen?

    Falls meine Änderung es noch nicht tut, könntest du folgendes machen:

    • eine ~/.quiltrc wie in https://wiki.debian.org/UsingQuilt#Encapsulated beschrieben anlegen
    • das yavdr experimental-main PPA mit Zugriff auf die Paketquellen einbinden: sudo add-apt-repository -s ppa:yavdr/experimental-main
    • die Pakete devscripts, build-essential, fakeroot installieren und die zum Bauen von lircd benötigten Abhängigkeiten mit sudo apt build-dep lirc
    • das Quellpaket herunterladen: apt source lirc
    • ins lirc-Verzeichnis wechseln lirc-0.10.1
    • meinen Patch entfernen quilt delete fix_mplay.patch
    • einen neuen Patch anlegen quilt new my_mplay.patch
    • die Datei bearbeiten quilt edit plugins/mplay.c
    • Nach dem Speichern der Änderungen den Patch aktualisieren quilt refresh
    • die Versionsnummer hochsetzen dch -l~local -m "added my patch" -Dbionic
    • das Paket mit dpkg-buildpackage -us -uc bauen lassen

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit deinem neuen Paket funktioniert lirc perfekt! Nochmals vielen Dank!!!

    Es wird ganz normal über die Services gestartet und mit sudo irw sehe ich die Tastendrücke.


    ... lediglich der VDR macht noch keinen Muckser... leider

  • ... lediglich der VDR macht noch keinen Muckser... leider

    Was sagt denn systemctl | grep lirc ?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Was sagt denn systemctl | grep lirc ?

    Code
    1. systemctl | grep lirc
    2. eventlircd.service loaded active running "eventlircd reads from kernel input devices and generates key presses on a lircd socket"
    3. inputlirc.service loaded active running Zeroconf LIRC daemon using input event devices
    4. irexec.service loaded active running Handle events from IR remotes decoded by lircd(8)
    5. lircd.service loaded active running Flexible IR remote input/output application support
    6. lircd2uinput.service loaded active running lircd2uinput daemon
    7. eventlircd.socket loaded active running eventlircd.socket


    wenn ich allerdings nach dem Booten eventlircd und anschließend den Service vdr neu starte funktioniert die Fernbedienung!


    Evtl. werden die Services nicht in der richtigen Reihenfolge gestartet(?)

  • Warum läuft da Inputlirc? Das könnte sich eventuell Kernel Input Devices schnappen, die sonst von eventlircd eingebunden werden - deaktivere das mal (systemctl mask inputlirc) und schau, was nach einem Neustart passiert.


    Die Dienste lircd, lircd2uinput und eventircd dürfen prinzipiell unabhängig voneinander starten:

    • Eventlircd bindet alle Kernel Input Devices dynamisch ein, die das Attibut ENV{eventlircd_enable}="true" tragen.
    • lircd2uinput schaut beim Start, ob ein Sockel /var/run/lirc/lircd0 vorhanden ist und kann nachträglich Lirc-kompatible Sockel über den Befehl lircd2uinput-add $SOCKEL zugewiesen bekommen. lircd2uinput kann per DBus Socket-Activation gestartet werden (also z.B. wenn man eines der lircd2uinput-* Programme aufruft) und erzeugt über uinput ein Kernel Input Device, das eventlircd dann über udev erkennt und einbindet.
    • Die lircd.service bekommt durch yavdr-ansible eine Erweiterung (https://github.com/yavdr/yavdr…ce.d/lircd2uinput.conf.j2), die dafür sorgt, dass lircd2uinput darüber bescheid weiß, wenn lircd gestartet oder gestoppt wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)