Posts by seahawk1986

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

    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:

    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=

    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.

    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):

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

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

    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?

    Mal eine kurze Frage zu dem vdr-addon-lifeguard-ng. Ist dafür das vdr-plugin-dbus2vdr nötig?

    Soweit ich das im Code sehen kann nicht - im Shutdown-Hook für den VDR wird ein Skript aufgerufen, das über DBus mit dem lifeguard-Daemon kommuniziert, aber der VDR ist daran nicht beteiligt (der würde den Shutdown ja selber vorher abbrechen, wenn er etwas dagegen hätte).

    Wenn ich die Elemente dem Array aber einzeln zuweise, dann läuft alles wie es soll.

    Das klingt nach einer dash vs. bash Geschichte - bei yavdr-ansible wird die Standard-Shell auf die bash gesetzt: https://github.com/yavdr/yavdr…s/configure_system.yml#L1


    Das Skript hat zwar die Bash im Shebang aber wenn es nicht ausführbar ist, ruft das vdr-shutdown Skript es mit sh auf, was dann mit der dash als Standard-Shell schief geht. Ich denke, ich baue da im Paket für das vdr-addon-acpiwakeup noch etwas ein, das die Datei ausführbar macht.

    Es wäre überhaupt sehr angenehm, wenn das plugin vdr-control (OSD via telnet) in den PPAs zur Verfügung stehen würde - das wäre toll (das brauchte ich in den letzten Jahren immer wieder).

    Wenn jemand einen Patch liefert, der es erlaubt das Plugin gegen den VDR 2.4.x zu bauen gerne... - ansonsten gibt es noch das vdr-plugin-remote, das eine ähnliche Funktionalität hat, wenn man es auf einem TCP-Port lauschen lässt (vgl. http://www.escape-edv.de/endriss/vdr/README) - also z.B. -p tcp:3333 als einziges Startargument nutzt.


    Die remote.conf kann man dann bei gestopptem VDR z.B. so ergänzen, wenn man von einer Linux-Konsole aus eine Telnet Sitzung nutzen will (oder softhddevice vorübergehend ohne -D starten lassen und die gewünschte Belegung anlernen, wenn kein remote.tcp-3333.* Eintrag in der remote.conf vorhanden ist):

    Es gab schon einige Meldungen dazu - daher gibt es einiges an Auswahl bei den softhddevice-Abkömmlingen: https://github.com/yavdr/yavdr…/Available-output-plugins


    softhddevice-vpp scheint mit bestimmten GT630/730 Karten Fehlfarben im OSD zu zeigen - in dem Fall würde ich mal vdr-plugin-softhddevice-openglosd-ffmpeg-2.8 oder ohne OSD-Beschleuningung das auf neuere ffmpeg-Versionen angepasste vdr-plugin-softhddevice probieren. Das sollte dann auch mit dem aktuellen automatisch vom Playbook installiertem nvidia-Treiber funktionieren.