Danke seahawk1986 und alle Beteiligten
Nun läuft alles wie es soll.
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?
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?
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 ...
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
root@vdr:/sys/devices/LNXSYSTM:00/LNXSYBUS:00# cat /proc/bus/input/devices
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=10000000000000 0
I: Bus=0003 Vendor=1209 Product=4445 Version=0111
N: Name="STMicroelectronics STM32 IRMP HID-KBD-Device"
P: Phys=usb-0000:00:15.0-7.4/input0
S: Sysfs=/devices/pci0000:00/0000:00:15.0/usb1/1-7/1-7.4/1-7.4:1.0/0003:1209:4445.0001/input/input1
U: Uniq=4973154D3237
H: Handlers=sysrq kbd event1
B: PROP=0
B: EV=100013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
(...)
Alles anzeigen
[edit]
Script ein wenig angepasst ($basepath) und der service startet korrekt:
sub GetButtonDevice {
my $basepath = '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input';
opendir(my $dh, $basepath) or die("failed to query for input device\n");
my ($input) = grep(/^input/, readdir($dh)) or die("no input device found\n");
closedir($dh);
opendir($dh, "$basepath/$input") or die("failed to query for event device\n");
my ($event) = grep(/^event/, readdir($dh)) or die("no event device found\n");
closedir($dh);
return "/dev/input/$event";
}
Alles anzeigen
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:
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=10000000000000 0
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=3
B: KEY=10000000000000 0
Alles anzeigen
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:
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"
ZitatBitte mal journalctl -f laufen lassen und den Power-Button drücken. Meldet denn dein modifiziertes vdrpbd einen Tastendruck?
gilbert@vdr:~$ journalctl -f
-- Logs begin at Wed 2019-07-17 18:19:34 CEST. --
Jul 20 15:26:31 vdr epgd[2044]: 527 DVB pending, mergeepg done after 632 ms
Jul 20 15:26:31 vdr epgd[2044]: Checking timers against actual epg and searchtimer settings
Jul 20 15:26:31 vdr epgd[2044]: Timers check done
Jul 20 15:26:31 vdr epgd[2044]: AUTOTIMER: Updating searchtimers due to 'events changed' (force)
Jul 20 15:26:31 vdr vdr[1754]: [2038] VNSI: Requesting clients to reload channel list
Jul 20 15:26:32 vdr epgd[2044]: AUTOTIMER: Update done after 551 ms, created (0) timers
Jul 20 15:26:32 vdr epgd[2044]: State now 'standby'
Jul 20 15:26:32 vdr epgd[2044]: Error: SVDRPCL: Connecting to '192.168.178.25:6419' Connection refused failed
Jul 20 15:26:43 vdr vdr[1754]: video: slow down video, duping frame
Jul 20 15:26:43 vdr vdr[1754]: video: 20:49:39.255 +470 1162 0/\ms 62+3 v-buf
Jul 20 15:27:14 vdr vdrpbd[842]: Power key pressed.
Jul 20 15:27:14 vdr vdr[1754]: [2042] SVDRP vdr < 127.0.0.1:37880 client connection accepted
Jul 20 15:27:14 vdr vdr[1754]: [2042] SVDRP vdr > 127.0.0.1:37880 server created
Jul 20 15:27:14 vdr vdr[1754]: [1754] Power button pressed
Jul 20 15:27:14 vdr vdr[1754]: [2042] SVDRP vdr < 127.0.0.1:37880 connection closed
Jul 20 15:27:14 vdr vdr[1754]: [2042] SVDRP vdr < 127.0.0.1:37880 server destroyed
Jul 20 15:27:14 vdr vdr[1754]: [1754] confirm: Taste drücken, um Ausschalten abzubrechen
Jul 20 15:27:14 vdr vdr[1754]: [1754] warning: Taste drücken, um Ausschalten abzubrechen
Jul 20 15:27:14 vdr vdr[1754]: [4324] animator thread thread started (pid=1754, tid=4324, prio=high)
Jul 20 15:27:20 vdr vdr[1754]: [4324] animator thread thread ended (pid=1754, tid=4324)
Alles anzeigen
ZitatEdit: 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!
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):
#!/usr/bin/env python3
import asyncio
import logging
import os
import signal
import sys
import time
import dbus
import pyudev
from evdev import InputDevice, ecodes, categorize
POWER_BTN_MAX = 4
logger = logging.getLogger(__name__)
logger.setLevel = logging.DEBUG
def systemd_inhibit():
"""prevent logind to handle power button events"""
bus = dbus.SystemBus()
proxy = bus.get_object('org.freedesktop.login1', '/org/freedesktop/login1')
login1 = dbus.Interface(proxy, 'org.freedesktop.login1.Manager')
try:
fd = login1.Inhibit('handle-power-key', 'yavdr-pbd',
"this replaces logind's power button handling",
'block').take()
except Exception as e:
logger.error("Could not inhibit handle-power-key", exc_info=True)
sys.exit(e)
return fd
def find_power_button_devices():
"""scan udev for devices with tag 'power-switch'"""
pwrbtns = []
context = pyudev.Context()
for device in context.list_devices(subsystem='input'):
if device.properties.get('eventlircd_enable') == 'true': # skip eventlircd devices
continue
if device.properties.get('NAME') == 'eventlircd:
continue
if device.tags._has_tag('power-switch'):
pwrbtns.append(device.device_node)
return pwrbtns
async def send_poweroff():
"""this function sends a KEY_POWER2 event to lirc clients"""
logger.info("send KEY_POWER2 to active program")
# TODO: use DBus-API (asyncio compatible: dbussy)
await asyncio.create_subprocess_exec('lircd2uinput-send', 'KEY_POWER2')
def read_event_factory():
power_btn_count = 0
last_power_btn_ts = float('nan')
async def read_events(dev) -> None:
nonlocal power_btn_count
nonlocal last_power_btn_ts
async for ev in dev.async_read_loop():
if ev.type != ecodes.EV_KEY:
continue
event = categorize(ev)
if event.keystate != event.key_down:
continue
if event.scancode == ecodes.KEY_POWER:
now = time.monotonic()
if last_power_btn_ts + 0.5 <= now:
power_btn_count = 0
else:
power_btn_count += 1
last_power_btn_ts = now
if power_btn_count >= POWER_BTN_MAX - 1:
logger.info("Initiating user-requested emergency reboot")
await asyncio.create_subprocess_exec('reboot', '--force')
power_btn_count = 0
else:
await send_poweroff()
return read_events
def main():
read_events = read_event_factory()
reader_tasks = []
pwrbtns = find_power_button_devices()
loop = asyncio.get_event_loop()
for p in pwrbtns:
try:
logger.debug(f"Creating InputDevice for {p}")
input_device = InputDevice(p)
except Exception:
logger.error(f"could not create InputDevice for {p}", exc_info=True)
continue
t = loop.create_task(read_events(input_device))
reader_tasks.append(t)
if reader_tasks:
inhibit_fd_num = systemd_inhibit()
async def signal_handler(signame):
os.close(inhibit_fd_num)
loop.stop()
for signame in ('SIGINT', 'SIGTERM'):
loop.add_signal_handler(
getattr(signal, signame),
lambda: asyncio.ensure_future(
signal_handler(signame)))
loop.run_forever()
if __name__ == '__main__':
main()
Alles anzeigen
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
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.
Da hast Du wohl viel richtig im Kopf
Das Paket ließ sich ohne Probleme installieren und die Übersetzung funktioniert
DANKE.
Gruß
Frank
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:
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -18,9 +18,9 @@
DDCI=0
T2MI=0
-CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS) @CFLAGS@
-LDFLAGS?=@LDFLAGS@
-LDFLAGS += -lpthread
+CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS)
+CFLAGS += $(EXTRA_CFLAGS) @CFLAGS@
+LDFLAGS += @LDFLAGS@ -lpthread
OS := $(shell $(CC) -v 2>&1 | grep Target | sed 's/Target: //' | cut -d- -f 2)
ARCH := $(shell $(CC) -v 2>&1 | grep Target | sed 's/Target: //' | cut -d- -f 1)
Alles anzeigen
Das Paket liegt dann in ppa:yavdr/experimental-main: https://launchpad.net/~yavdr/+…shed&field.series_filter=
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:
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -18,9 +18,10 @@
DDCI=0
T2MI=0
-CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS) @CFLAGS@
-LDFLAGS?=@LDFLAGS@
-LDFLAGS += -lpthread
+CFLAGS?=-Wall -Wno-switch -ggdb -fPIC
+CFLAGS += $(EXTRA_CFLAGS) @CFLAGS@
+LDFLAGS += @LDFLAGS@ -lpthread
+CPPFLAGS += @CPPFLAGS@
OS := $(shell $(CC) -v 2>&1 | grep Target | sed 's/Target: //' | cut -d- -f 2)
ARCH := $(shell $(CC) -v 2>&1 | grep Target | sed 's/Target: //' | cut -d- -f 1)
--- a/Makefile.in
+++ b/Makefile.in
@@ -2,23 +2,23 @@
AUTOMAKE_OPTIONS = foreign
TARGET=minisatip
-$(TARGET): FORCE
+# pull in dependency info for *existing* .o files
+ifneq "$(MAKECMDGOALS)" "clean"
+-include $(DEPS)
+endif
+
+$(TARGET):
$(MAKE) -C src
-clean: FORCE
+clean:
$(MAKE) -C src $@
$(MAKE) -C tests $@
-test: FORCE
- $(MAKE) -C src clean
+test:
+ $(MAKE) -C src
$(MAKE) -C tests $@
-debug: FORCE
+debug:
$(MAKE) -C src DEBUG=1
FORCE:
-
-# pull in dependency info for *existing* .o files
-ifneq "$(MAKECMDGOALS)" "clean"
--include $(DEPS)
-endif
--- a/tests/Makefile.in
+++ b/tests/Makefile.in
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = foreign
BUILDDIR := ../build
-CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS) -I../src
+CFLAGS?=-Wall -Wno-switch -ggdb -fPIC $(EXTRA_CFLAGS)
LDFLAGS?=-lpthread
OS := $(shell $(CC) -v 2>&1 | grep Target | sed 's/Target: //' | cut -d- -f 2)
@@ -24,6 +24,7 @@
LIBS+=dvben50221 dvbapi ucsi
CFLAGS += -DAXE
#CFLAGS += -fsanitize=address -fno-omit-frame-pointer -fsanitize=leak -fsanitize=null
+CFLAGS += -I../src
CFLAGS += -DENIGMA
CFLAGS += -DTESTING
Alles anzeigen
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!