• Danke seahawk1986 und alle Beteiligten

    Nun läuft alles wie es soll.

  • Kennt jemand dieses Problem?



    Jul 19 14:21:55 vdr vdrpbd[796]: failed to query for input device

    Jul 19 14:21:55 vdr systemd[1]: vdrpbd.service: Main process exited, code=exited, status=1/FAILURE

    Jul 19 14:21:55 vdr systemd[1]: vdrpbd.service: Failed with result 'exit-code'.



    Hängt das evtl. zusammen, dass ich den VDR nur über Tastatur (bzw. dem irmp-auf-stm32-ein-usb-hid-keyboard von JRIE ) steuern will und daher kein LIRC bei der Installation ausgewählt habe?

    Yavdr auf Yammy / 2 Kabel Empfänger / Asrock j4105-itx / IRMP KDB

  • Die Meldung kommt laut Quellcode, wenn das Verzeichnis /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input nicht geöffnet werden kann.


    Was sagen denn ls /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input und cat /proc/bus/input/devices auf dem betroffenen System?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die Meldung kommt laut Quellcode, wenn das Verzeichnis /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input nicht geöffnet werden kann.


    Was sagen denn ls /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input und cat /proc/bus/input/devices auf dem betroffenen System?


    Da fehlt offenbar ein directory ...

    Code
    root@vdr:/sys/devices/LNXSYSTM:00/LNXSYBUS:00# ls /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input
    ls: cannot access '/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input': No such file or directory
    
    
    root@vdr:/sys/devices/LNXSYSTM:00/LNXSYBUS:00# ls /sys/devices/LNXSYSTM\:00
    hid  LNXSYBUS:00  LNXSYBUS:01  modalias  path  power  subsystem  uevent



    [edit]


    Script ein wenig angepasst ($basepath) und der service startet korrekt:

    Yavdr auf Yammy / 2 Kabel Empfänger / Asrock j4105-itx / IRMP KDB

    Einmal editiert, zuletzt von Grillbert ()

  • Dann müsste man M-Reimer darauf aufmerksam machen, dass es da noch alternative Pfade für den Power-Button geben kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich frage mich ja ob der "korrekt gestartete" Service dann auch funktioniert. Was passiert denn wenn der physikalische Power-Button am Board dann gedrückt wird? Hat das Board überhaupt einen?


    Bei mir sieht das so aus:



    Der unter "LNXSYBUS" existiert bei mir also auch. Keine Ahnung wie man hier ein Event triggern kann aber mit dem Power-Button auf jeden Fall nicht.


    Bitte mal journalctl -f laufen lassen und den Power-Button drücken. Meldet denn dein modifiziertes vdrpbd einen Tastendruck?


    Da ich schonmal dabei war habe ich Kodi-Support gepusht. Liegt hier schon länger rum.


    Edit: Mach mal "modprobe button". Eventuell ist dein Kernel mit "CONFIG_ACPI_BUTTON=m" gebaut und aus irgendeinem Grund wird das Modul nicht automatisch geladen.

  • Zumindest bei den regulären Ubuntu-Kerneln wurde das nicht als eigenständiges Modul gebaut:

    Code
    $ grep CONFIG_ACPI_BUTTON /boot/config*
    /boot/config-4.15.0-54-generic:CONFIG_ACPI_BUTTON=y
    /boot/config-4.18.0-24-generic:CONFIG_ACPI_BUTTON=y
    /boot/config-4.18.0-25-generic:CONFIG_ACPI_BUTTON=y
    $ grep acpi/button /lib/modules/$(uname -r)/modules.builtin
    kernel/drivers/acpi/button.ko

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich frage mich ja ob der "korrekt gestartete" Service dann auch funktioniert. Was passiert denn wenn der physikalische Power-Button am Board dann gedrückt wird? Hat das Board überhaupt einen?

    Das sieht zumindest korrekt aus - Yavdr meldet im Display sowas wie "Taste Drücken um Ausschalten abzubrechen"



    Zitat

    Bitte mal journalctl -f laufen lassen und den Power-Button drücken. Meldet denn dein modifiziertes vdrpbd einen Tastendruck?



    Zitat

    Edit: Mach mal "modprobe button". Eventuell ist dein Kernel mit "CONFIG_ACPI_BUTTON=m" gebaut und aus irgendeinem Grund wird das Modul nicht automatisch geladen.

    Das liefert schlicht gar nix!

    Yavdr auf Yammy / 2 Kabel Empfänger / Asrock j4105-itx / IRMP KDB

  • Wenn es gar nichts liefert wurde das Modul geladen. Frage ist ob das was an den Input Devices ändert.


    Problem ist das das "Powerbutton Device", das du hast, bei mir auch existiert. Nur kommt da bei mir definitiv nicht der Powerbutton an.

  • Ich habe mal etwas durch den Kernel-Source gesucht und was da mit dem Power-Button gemacht wird ist schwer zu durchschauen.

    Allerdings ist "PNP0C0C" eine valide Kennung für einen "Power Button".

    Ich hab das jetzt mal als "zweite Priorität" eingebaut. Wenn der "normale" Power Button nicht gefunden wird, dann erfolgt ein Fallback auf diesen zweiten Pfad.

    Verfügbar als "Version 2.0.0"

    Download von hier als Snapshot. Das mit der separaten Ablage in Redmine tue ich mir nicht mehr an.

    https://projects.vdr-developer.org/git/vdrpbd.git/


    Edit: "Kodi Mode" wird nochmal überarbeitet. So wie es aktuell drin ist werden Aufnahmen abgebrochen und Kodi fährt knallhart runter.

  • Ich habe mal nachgesehen, was wie logind das macht - das scheint zu versuchen alle Event-Devices auslesen, die laut udev das Subsystem input haben und den Tag power-switch tragen.


    Mal grob für yavdr-ansible mit Abhängigkeit zu python3-pyudev, python3-dbus, python3-evdev sowie lircd2uinput und dem python3-yavdrfrontend (das reagiert unabhängig davon, ob gerade ein VDR-Frontend oder KODI aktiv ist auf KEY_POWER2 auf dem eventlircd-Sockel und tut dann das Richtige (Frontend stopppen, VDR regelmäßig dazu auffordern herunterzufahren):

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Auf alle Devices wollte ich bewusst nicht gehen. So kann ich den Power-Button gezielt vom X-Server abkoppeln. Hintergründe hier im Kommentar:

    https://projects.vdr-developer…drpbd.git/tree/vdrpbd#n83


    Und entsprechend simpel ist auch mein verbesserter Kodi-Support. Ich filtere für Kodi das "KEY_POWER" einfach nicht weg weil Kodi bereits sauber drauf reagiert. Bleibt für ein System mit Kodi also eigentlich nurnoch das "Emergency Reboot" Feature übrig. Wer das nicht braucht kann auf einem System mit Kodi eigentlich einfach auf vdrpbd verzichten.


    Ich habe vdrpbd eigentlich auch nur nochmal angepasst weil yavdr das scheinbar nutzt.

    Im Prinzip könnte man auf solche Tools ganz verzichten wenn wenigstens ein Ausgabe-Plugin so angepasst wird, dass es KEY_POWER, das wie jede ganz normale Taste im X-Server ankommt, korrekt behandelt.

  • Hallo seahawk1986 ,


    ich versuche gerade das | translate im Template menuorg.xml.j2 zu verstehen.

    Ich nehme mal an hier soll der angezeigte Text, mittels Filter-Plugin translate_yavdr.py übersetzt werden, leider funktioniert das bei mir nicht.

    Hast Du eine Idee wo ich bei der Fehlersuche ansetzen kann? Host ist ein Rechner mit Siduction (Debian Sid).


    Gruß

    Frank

    VDR User: 2127
    YaVDR-focal , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: Digital Devices Cine S2 V6
    YaVDR-focal (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: Sundtek SkyTV Ultimate Dual, Miscellaneous: epgd, pihole

    YaVDR-focal (headless), System: HP 260 G2 DM, DVB-S: Sundtek SkyTV Ultimate Dual

  • Wenn ich das richtig im Kopf habe, werden die Templates auf dem Recher expandiert, der Ansible ausführt - da müsste dann auch das Lokalisierungs-Paket yavdr-i18n installiert sein, damit der translate-Filter aus der translate_yavdr.py die Dateien finden kann.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da hast Du wohl viel richtig im Kopf :wow:]

    Das Paket ließ sich ohne Probleme installieren und die Übersetzung funktioniert:thumbup:

    DANKE.


    Gruß

    Frank

    VDR User: 2127
    YaVDR-focal , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: Digital Devices Cine S2 V6
    YaVDR-focal (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: Sundtek SkyTV Ultimate Dual, Miscellaneous: epgd, pihole

    YaVDR-focal (headless), System: HP 260 G2 DM, DVB-S: Sundtek SkyTV Ultimate Dual

  • Ich habe endlich den Fehler in einem Makefile-Template von minisatip gefunden, der verhindert hat, dass sich das Paket mit Netceiver-Unterstützung bauen ließ (die CFLAGS und LDFLAGS mit den nötigen Includes und Linker-Flags werden nicht gesetzt, wenn die Build-Umgebung die Variablen bereits definiert hat) - vielleicht kann mal jemand mit entsprechender Hardware ausprobieren, ob das auch tatsächlich klappt:


    Das Paket liegt dann in ppa:yavdr/experimental-main: https://launchpad.net/~yavdr/+…shed&field.series_filter=

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Damit hatte ich gestern auch zu kämpfen.

    Ich hab mir etwas zusammengefummelt. Dein Fix kommt einer "sauberen Lösung" aber deutlich näher.


    +CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS)

    +CFLAGS += $(EXTRA_CFLAGS) @CFLAGS@

    +LDFLAGS += @LDFLAGS@ -lpthread


    Ist das nicht redundant?


    Wenn CFLAGS nicht gesetzt, dann setze auf $VORGABE +$EXTRA_CFLAGS

    Füge zu den CFLAGS dann $EXTRA_CFLAGS hinzu gefolgt von den CFLAGS aus configure.

    Kann dann das $(EXTRA_CFLAGS) in der ersten Zeile nicht entfallen? Wird ja sowieso in jedem Fall in der zweiten Zeile eingebaut.


    Wenn du die Zeit hast, dann wäre es echt gut wenn du einen sauberen Fix direkt als Pull-Request für minisatip einstellen könntest.

  • Ist das nicht redundant?

    Ja, mir ging es gestern nur darum dass es überhaupt mit der Netceiver-Unterstützung als Debian-Paket baut.


    Wenn du die Zeit hast, dann wäre es echt gut wenn du einen sauberen Fix direkt als Pull-Request für minisatip einstellen könntest.

    Ich musste da noch einiges mehr umstellen, u.a. wurde das clean-Target vor den Tests aufgerufen, so dass die Tests fehlschlugen. Ich habe die nächsten Wochen voraussichtlich keine Zeit dafür, aber das sind die Patches aus dem Paket - nicht schön, aber es scheint zumindest für Debian-Pakete zu funktionieren:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich könnte das später als Pull-Request einstellen. Wäre mir lieber das alsbald möglich "upstream" zu haben um nicht auf Dauer selber patchen zu müssen.


    Was hat das mit diesem "FORCE" auf sich? Ist "FORCE" nicht ein leeres Target?

  • Ich habe das ehrlich gesagt nicht verstanden, warum die das das eingebaut hatten und nur einen funktionierenden Stand aus einer älteren Version wiederhergestellt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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