Beiträge von seahawk1986

    Die autostart.conf sieht aktuell so aus, die beiden Plugins sind auch installiert:

    Ich bekomme einen Speicherzugriffsfehler, wenn ich den VDR mit gdb starte (der komplette Backtrace ist im Anhang):

    Vielleicht kann Ulrich Eckhardt da etwas dazu sagen.


    Bei yaVDR 0.6 kommt udisks (nicht udisks2) zum Einsatz und ins Syslog schreibt der VDR folgendes:

    Dateien

    • backtrace.txt

      (12,18 kB, 11 Mal heruntergeladen, zuletzt: )

    Da ist noch ein Fehler in der Konfigurationsdatei, die mit dem Paket ausgeliefert wird - laut Quellcode ist das Zeichen für eine Auskommentierte Zeile ein ;, in der /etc/vdr/plugins/autostart/autostart.conf werden aber zum Teil # genutzt.


    Jetzt habe ich noch einen Segfault beim Zugriff auf udisks über DBus (und die Fehlermeldung Argument is not string #000 im Log) - mal sehen, woran das liegt.

    Die CIR-Empfänger laufen nicht über lircd2uinput, sondern die Events gehen direkt von dem vom rc-core Treiber angelegten Kernel Input Device an eventlircd.


    Hast du das Problem mit den doppelten Tastendrücken nur im VDR oder auch in KODI?


    Falls es nur im VDR auftaucht, kannst du dessen Repeat-Filter hochdrehen - in den Einstellungen -> Sonstiges -> "Fernbedienung Wiederholungsverzögerung (ms)" auf ca. 350 ms setzen (mit dem Wert kannst du ein bisschen spielen). Der Hintergrund ist, dass viele RC-5 und RC-6 Fernbedienungen den IR-Frame bei einem Tastendruck ein paar Mal senden (meistens 3x, aber das kann variieren) und da die Wiederholungen ca. 110 - 115 ms auseinander liegen, muss man den Wert so lange hoch drehen, bis unabsichtliche doppelte Tastendrücke weg sind.

    Ich hatte aber vorher schon neu installiert (Ubuntu geht ja in ca. 15 Minuten) und trotz einer Fehlermeldung von ansible (bzgl. nvidia) habe ich nach Reboot ein Bild, aber keinen Ton

    Weißt du eventuell noch, was in der Fehlermeldung stand? Ggf. muss man den installer noch ein zweites Mal aufrufen, wenn vor dem Reboot der nvidia-Treiber nicht erfolgreich geladen werden konnte, damit die automatische Erkennung des 50Hz-Modul klappt.


    Zum Ton: du kannst im VDR-OSD das pulsecontrol-Plugin nutzen, um die Audioausgabe zu konfigurieren. Normalerweise genügt es unter "verschiebe Wiedergabe" den gewünschten Ausgang zu wählen.

    die Startzeit vom Reboot bis zum Bild ist super schnell < 1 Minute

    Zeig mal die Ausgabe von systemd-analyze blame und systemd-analyze critical-chain, vermutlich kann man mit einer statischen IPv4-Addresse und deaktivertem DHCP für IPv6 noch einiges rausholen.

    aber seit Umstellen auf den Skin osd2web (via OSD) geht die Fernbedienung nicht mehr

    Damit trittst du die Kontrolle an osd2web ab - das bietet auf Port 4444 das Webinterface an und nachdem man sich ein Theme ausgesucht hat, gibt es unten links ein Knöpfchen, mit denen man eine Ferbedienung einblenden und das OSD aufrufen und steuern kann.


    Wenn man das nicht über osd2web zurücksetzen will, kann man man den VDR mit systemctl stop vdr stoppen, dann in der /var/lib/vdr/setup.confden Wert OSDSkin = lcars setzenund startet den VDR wieder mit systemctl start vdr starten.

    Oder man nimmt dbus2vdr, während der VDR läuft: vdr-dbus-send /Skin skin.SetSkin string:'lcars'

    allerdings gibts nach Aufwachen (auch sauschnell) "buntes Schneegestöber" - die Konsole geht aber

    Standby habe ich noch nicht ausprobiert und Skripte, die den VDR vor dem Standby stoppen oder die DVB-Treiber neu laden lassen, gibt es noch nicht - die müsste noch jemand erarbeiten.

    Wie kann man dich/euch dabei am besten unterstützen (wenn man kein großer C++ Programmierer ist)?

    Ich bin kein großer C++ Programmierer, nach Möglichkeit bleibe ich bei Shell-Skripten und Python - halt überall da, wo man um die Geschwindigkeitsvorteile von C++ herum kommt ...

    Ich dachte allerdings die Fernbedienung wird wie eine Tastatur behandelt und würde ootb funktionieren. Wie gesagt, mit evtest werden die Tasten „Remote.conf“ - konform angezeigt.

    Ja, aber es gibt zwei Probleme: zum einen generiert die Fernbedienung keine Wiederholungs-Events für gedrückt gehaltene Tasten (das kann der X-Server kompensieren) und zum anderen nutzt sie Tasten, die der X-Server nicht abbilden kann. (wenn sie einen Tastencode >255 haben, wie man iin https://github.com/torvalds/li…linux/input-event-codes.h nachlesen kann). Deswegen der Umweg über ps3remote, das als Adapter zu eventlircd fungiert - es öffnet das Eingabegerät exklusiv, liest die Events aus, fügt Wiederholungsevents ein und gibt die Tastendrücke über uinput so aus, dass eventlircd damit gut zurecht kommt und von dessen Lirc-kompatiblen Sockel lesen dann der VDR und KODI.

    In yavdr-ansible fehlt bislang noch das Python-Skript ps3remote (unter yaVDR 0.6 stammte das aus yavdr-base), das die Tastendrücke vom Kernel Input Device in von eventlircd verwertbare Events umsetzt. Was du aktuell siehst, sind vermutlich die Input-Events <255, die vom X-Server an den VDR weiter gereicht werden.


    Ich habe das Skript schon auf Python3 umgestellt, das muss als /usr/bin/ps3remote abgelegt und ausführbar gemacht werden: ps3remote.py.txt

    Als zusätzliche Abhängigkeit benötigt es das Paket python3-evdev.


    Die Systemd-Unit dafür sieht dann so aus:

    Code: /lib/systemd/system/ps3remote@.service
    1. [Unit]
    2. Description=ps3remote - a daemon for the PS3 Bluetooth remote
    3. [Service]
    4. ExecStart=/usr/bin/ps3remote -s /dev/input/%I

    Die udev-Regel, die die Systemd-Unit startet, sollte dann so aussehen (die vorhandene Version aus dem Paket yavdr-remote einfach überschreiben):

    Code: /lib/udev/rules.d/99-ps3remote.rules
    1. ACTION=="add",SUBSYSTEM=="input", ENV{ID_VENDOR_ID}=="0bf8", ENV{ID_MODEL_ID}=="1003",TAG+="systemd",ENV{SYSTEMD_WANTS}="ps3remote@%k.service",SYMLINK+="input/ps3"


    Von eventlircd wird dann die ps3remote.evmap genutzt, um die Tastendrücke auf den yaVDR-Standard zu bringen: https://github.com/yavdr/yavdr…ventlircd-names.rules#L50


    Vielleicht kannst du das mal bei dir ausprobieren (insbesondere, ob die udev-Regel greift, sonst man mit udevadm info --query=all --name=/dev/input/eventXX (das XX durch die tatsächliche Nummer für das Gerät ersetzen) nachsehen, was das für udev-Attribute bei dir hat.


    Wenn das so passt, kann ich es ein Paket dafür schnüren und es von yavdr-ansible mitinstallieren lassen.