[clausmuus]

Zu Deiner letzten Frage: Nein, so ein Problem dürfte es nicht geben.

Das Problem mit der Power Taste dürfte sein, dass diese ein Event mit einem Namen sendet, den nur der Xserver versteht. Vermutlich hat das bisher keiner von uns der den VDR ohne Xserver nutzt ausprobiert, weshalb das bisher nicht aufgefallen ist.
Du kannst mal folgendes versuchen:
Rufe "keyd monitor" auf, und drücke dann die Power Taste. Nenne mir den Namen des Events das dies auslöst. Du kannst auch mal zum Vergleich testen, ob die Taste bei laufendem Xserver (wenn Du z.B. die Setup App gestartet hast) eine anderes Event angezeigt wird.

[purzel]

Zu Deiner letzten Frage: Nein, so ein Problem dürfte es nicht geben.

Sollte, müsste, dürfte ... alles so Worte, die in der IT gerne mal nicht so laufen wie erwartet 

Das Problem mit der Power Taste ...
Rufe "keyd monitor" auf, und drücke dann die Power Taste. Nenne mir den Namen des Events das dies auslöst. Du kannst auch mal zum Vergleich testen, ob die Taste bei laufendem Xserver (wenn Du z.B. die Setup App gestartet hast) eine anderes Event angezeigt wird.

Code: [Select]

...
device added: 0fac:0ade:bea394c0 keyd virtual keyboard (/dev/input/event8)
...
keyd virtual keyboard   0fac:0ade:bea394c0      enter down
keyd virtual keyboard   0fac:0ade:bea394c0      enter up
keyd virtual keyboard   0fac:0ade:bea394c0      power down
keyd virtual keyboard   0fac:0ade:bea394c0      power up
Session closed. Bei laufendem Setup/XServer kommen exakt die selben Events mit entsprechendem Hex-Wert.
So langsam befürchte ich - S O R R Y ! ! ! - ein Hardwareproblem mit dem verwendeten Taster, das ist nämlich ein uraltes Ding aus der Bastelkiste - passte halt zufällig so schön in eine vorhandene Bohrung im Gehäuse 
Ich tausche den nachher mal aus. Seufz!

ABER höchst spannende Erkenntnis: ich habe ja nun den Power-Knopf gedrückt bei laufendem XServer/Setup - und er fährt ruck-zuck 'runter!!
Das spricht m.M.n. immerhin für die Theorie, dass VAAPI (mit)verantwortlich ist für das lahme Herunterfahren inkl. der "A stop job is running for Foreground App" Meldung.

[franky]

@claus
Ich habe das mit dem PowerButton noch mal getestet.
Bei einem Testsystem mit vaapivideo hat der PwerButton nicht reagiert, bei einem anderen System aber schon.
Beim System mit dem funktionierenden PowerButton ist das vdr-plugin-usbkbd installiert und beim andern nicht.

Bei softhddevice mit laufendem XServer funktioniert der PowerButton mit und ohne usbkbd Plugin.
Ohne usbkbd Plugin wird der PowerButton über den XServer und die XKeySym.conf ausgewertet.
Ist das vdr-plugin-usbkbd installiert wird der PowerButton über die USBKBD.conf ausgewertet.

Bei vaapivideo läuft ja kein XServer weshalb ohne usbkbd die Tastendrücke über die KBD.conf ausgewertet werden.
In der KBD.conf gibt es nur einen Eintrag KBD.Power für F12, weshalb dann auch nur F12 funktioniert.
Ist vdr-plugin-usbkbd installiert ist ja die USBKBD.conf für die Auswertung zuständig und dort gibt es für USBKBD.Power außer für F12 noch weitere Einträge, die dann den HW-PowerButton auswerten.

@purzel
Die Lösung für das PowerButton-Problem bei vaapivideo wäre also das usbkbd Plugin.
Ist halt die Frage wie das wiederum mit deinem rcu Plugin zusammen funktioniert.

[clausmuus]

@franky,
Diene Erkenntnisse treffen größtenteils zu. Nur die Schlussfolgerung nicht.
Es würde auch ohne das usbkbd Plugin funktionieren. Dafür gibt es zwei Möglichkeiten:
- ich füge eine Übersetzung des "power" events zu F12 zur keyd Konfiguration hinzu
- ich ergänze die KBD.conf um den Tastencode für die Power Taste. Wobei ich vermute, dass dieses Event beim VDR KEY Handler gar nicht ankommt, weil es sich um ein Event handelt, dass auf der Console nicht bekannt ist.

Die sicher funktionierende Lösung ist also, dass Du die Datei /etc/keyd/power.conf mit diesem Inhalt erstellst:

Code: [Select]

[ids]

*

[main]

power = f12Eventuell musst Du anstelle des * die ID 0fac:0ade eintragen. Sollte aber nicht nötig sein.

[purzel]

Soo...

Ich habe den Taster durch einen recht Hochwertigen ausgetauscht, der Lötkolben ist schon wieder kalt 

Meine Theorie, dass es (auch?) daran lag, wird ggf. dadurch untermauert, dass das EINschalten ja eine echte Hardware-Funktion ist und vermutlich Mikrosekunden des Kontakt-Schließens ausreichen dürften - für's AUSschalten ja aber der Tastendruck durch irgendeine Software erkannt werden muss was möglicherweise "einen Tick" länger dauert als der der alte Taster  seine Kontakte schließt (wenn überhaupt)... Bisher waren ohne Probleme alle inzwischen fünf Tests des Ein- und Austastens sofort erfolgreich. Allerdings kommt beim Drücken des Hardware-Powerknopfes NICHT die OSD-Meldung "Taste drücken um Ausschalten abzubrechen" - was nicht so wirklich schlimm ist. Kommt DAS Ausschalten evtl. jetzt vom Betriebssystem, z.B. ACPI?

Im Moment jedenfalls bin ich der Meinung, dass es ohne das vdr-plugin-usbkbd und auch ohne die von Claus vorgeschlagene /etc/keyd/power.conf gehen "sollte" (siehe oben, hihi  ) und somit natürlich zunächst keine Inkompatibilitäten zum RCU Plugin zu befürchten sind. ABER: Der neue Taster hat (im Grunde erwartungsgemäß) keine Auswirkung auf das Trödeln beim Herunterfahren - weswegen ich noch nicht davon ab bin, doch wieder zum softhddevice, nicht aber mit dem Intel-Image, zurückzukehren. Hm.
Kann man denn nicht irgendwie herausfinden, was das Herunterfahren blockiert? Mit XServer passiert's ja nicht, siehe auch oben (Erkenntnis in Fettschrift)

[clausmuus]

Mit meiner vorgeschlagenen Änderung würde im OSD die Nachfrage kommen.
Außerdem gibt es im Webif Setup die Möglichkeit das umzuschalten (was aber nicht zusammen mit meiner Vorgeschlagenen Änderung funktioniert).

[clausmuus]

Ich hab mir die Setting noch mal angeschaut. Wenn "Sofort herunter fahren wenn die Taste am Gerät gedrückt wird" aktiviert ist, sollte die Taste immer funktionieren, egal ob Xserver oder nicht. Andernfalls könnte es sein, dass die Taste nur unter Xserver funktioniert.

[franky]

Claus das stimmt schon, dass wenn "Sofort herunter fahren wenn die Taste am Gerät gedrückt wird" im WebIF aktiviert ist, das System auch ohne XServer sofort herunterfährt.
Sowie ich mich erinnere war das aber dafür gedacht, dass man das System auch dann mit der Powertaste herunterfahren kann, wenn kein VDR läuft.
Wirkt also wie das "AUSSCHALTEN" unter Dienste im WebIF.
Der Nachteil ist dann aber, dass der VDR nicht normal beendet wird und Wakeup Timer nicht gesetzt werden.

[purzel]

Moin.

Bisher waren ohne Probleme alle inzwischen fünf Tests des Ein- und Austastens sofort erfolgreich.

Allerdings habe bzw. hatte ich die Option "Sofort herunter fahren wenn die Taste am Gerät gedrückt wird" aktiv.
Schalte ich die aus, fährt er (ohne oder mit Claus' Tipp mit dem keyd - egal) nicht mehr mit Powerknopf 'runter; trotz systemctl restart keyd nach jeder Änderung der /etc/keyd/power.conf 
Hier habe ich übrigens mehrere IDs probiert: *, 0000:0001 (Power Button), 04ca:005a (Keyboard), 0fac:0ade (virtual keyboard). Die Letzte ist die, die `keyd monitor` als event ausgibt wenn ich den Powerknopf drücke; die anderen stammen aus der Auflistung von `keyd monitor`. Mit * in /etc/keyd/power.conf

Code: [Select]

root@MLD:~# keyd monitor
device added: 0fac:1ade:d2b36ae6 keyd virtual pointer (/dev/input/event9)
device added: 0fac:0ade:bea394c0 keyd virtual keyboard (/dev/input/event8)
device added: 0000:0006:bdb72f48 Video Bus (/dev/input/event7)
device added: 046d:c05a:6d56d678 Logitech USB Optical Mouse (/dev/input/event6)
device added: 04ca:005a:08a39704 Lite-On Technology Corp. USB Multimedia Keyboard System Control (/dev/input/event5)
device added: 04ca:005a:f6d19e78 Lite-On Technology Corp. USB Multimedia Keyboard Consumer Contro/dev/input/event4 (/dev/input/event4)
device added: 04ca:005a:99480b1e Lite-On Technology Corp. USB Multimedia Keyboard (/dev/input/event3)
device added: 0000:0001:48a093aa Power Button (/dev/input/event2)
device added: 0000:0001:48a093aa Power Button (/dev/input/event1)
device added: 0000:0003:86db4035 Sleep Button (/dev/input/event0)
keyd virtual keyboard   0fac:0ade:bea394c0      power down
keyd virtual keyboard   0fac:0ade:bea394c0      power up
Vielleicht auch nicht unwichtig:
WebIf -> Dienste -> System -> Ausschalten -> sehr schnelles Herunterfahren
WebIf -> drei Punkte rechts oben -> Ausschalten -> lahm (wie bei Powerknopf)

Übrigens fand ich früher (MLD 5.3) den Fortschrittbalken unterm MLD-Logo beim Booten und Runterfahren schönerer als die jetzigen drei Punkte in der Ecke 

[franky]

Vielleicht auch nicht unwichtig:
WebIf -> Dienste -> System -> Ausschalten -> sehr schnelles Herunterfahren
WebIf -> drei Punkte rechts oben -> Ausschalten -> lahm (wie bei Powerknopf)

Übrigens fand ich früher (MLD 5.3) den Fortschrittbalken unterm MLD-Logo beim Booten und Runterfahren schönerer als die jetzigen drei Punkte in der Ecke 

Wie ich ja weiter oben schon geschrieben hatte, bewirkt die Einstellung (WebIf -> Dienste -> System -> Ausschalten) ein sehr schnelles Herunterfahren bei dem der VDR nicht sauber beendet wird.
Eben mit der Folge, dass programmierte Wakeup Timer nicht gesetzt werden.
Somit scheint der saubere VDR-Shutdown an dieser Verzögerung beteiligt zu sein.

Da ich das Problem mit dem verzögerten Shutdown bei Verwendung von vaapivideo bei meinen Systemen nicht reproduzieren konnte, habe ich ausführlicher getestet.
Ich habe herausgefunden an was es liegt und weshalb es bei meinen Systemen mit vaapivideo bisher nicht aufgetreten ist.

Meine Systeme mit vaapivideo wurden alle im April installiert und seither immer upgedatet, weshalb ich mal mit einem alten Image vom April 2026 neu installiert habe.
Bei diesem neu installierten System mit vaapivideo ist das System mit F12 sofort ohne größere Verzögerung heruntergefahren.
Ich habe dann mit dem aktuellen Image neu installiert und da braucht das System dann fast 2 Minuten für den Shutdown nachdem das TV-Bild weg ist.
Ich habe dann weitere Images vom Juni und Mai getestet wo der Shutdown ebenfalls stark verzögert war.

Beim Vergleich der Pakete, die bei einem Distupgrade der Images vom April und Mai auf den aktuellen Stand zu aktualisieren waren, ist beim April Image als Unterschied das Paket Keyd übriggeblieben.
Ich habe dann beim mit dem April Image installierten System, bei dem es keine Shutdown Verzögerung gab, nur das keyd Paket aktualisiert und danach auch die Shutdown Verzögerung.
Die Ursache für diese Verzögerung ist also eindeutig das Anfang Mai aktualisierte keyd Paket mit dem es wohl ohne laufenden XServer diese Verzögerung beim Shutdown gibt.

Da das Problem bei meinen aktualisierten Systemen nicht auftritt und damals keyd im Rahmen der Implementierung des usbkbd Plugin auf eine neue Version aktualisiert werden musste, habe ich mal das usbkbd Plugin installiert.
Und siehe da, das System fährt nach der Installation des usbkbd Plugin wieder ohne große Verzögerung herunter.

Die Aktualisierung der keyd Version von 2.4.3 auf 2.6.0 war damals Anfang Mai nötig, damit wieder alle USB FB-Empfängern mit dem neuen Tastenmapping funktionieren.
Mit der alten keyd Version 2.4.3 hatten nur noch "echte" Tastatur-Empfänger incl. der RP2040-Empfänger funktioniert.
Ein Fallback auf die alte keyd Version ist daher keine Option.

Mit dem usbkbd Plugin gibt es also eine Lösung mit der die Shutdown-Verzögerung nicht auftritt und auch der HW-PowerButten mit vaapivideo einwandfrei funktioniert.
Ein aus meiner Sicht großer Vorteil des usbkbd Plugin ist ja die Möglichkeit, auch im VDR-OSD Buchstaben und Ziffern direkt über die Tastatur eingegeben zu können.
Da ich neben einer FB schon immer eine Mini-Keyboard angeschlossen habe, um Kodi, Chromium und das WebIF am TV vernünftig bedienen zu können, verwende ich das ubkbd Plugin seit Mai auf allen Systemen.

Zum Thema grauer Bildschirm beim Booten:
Eigentlich gibt es anstatt des grauen Bildschirms mit den drei Punkten ein Plymouth animiertes, pulsierendes MLD Logo.
Mir ist schon aufgefallen, dass es da bei einigen Intel-GPUs Probleme, besonders in Verbindung mit vaapivideo, Probleme mit Plymouth gibt und dann der graue Bildschirm beim Booten angezeigt wird.
Bei meinem Intel NUC8i3 (CoffeeLake Generation) wird immer das MLD-Logo angezeigt.
Ist aber eben keine generelles Verhalten der MLD 6.5.
Hast du den grauen Bildschirm eigentlich bei beiden Images und auch bei softhddevice Intel?

[purzel]

Wow! Ich bin immer wieder begeistert von diesem tollen Forum, besonders dem MLD-Team - vielen vielen Dank für die Unterstützung!

Ich habe natürlich nicht damit gerechnet was ich "damit lostrete", das artet ja fast in Grundlagenforschung aus 

Dass Du (Franky) oben DIE Stelle mit dem sehr schnellen Runterfahren meintest war mir zu dem Zeitpunkt nicht klar, jetzt natürlich schon.

Da das Problem bei meinen aktualisierten Systemen nicht auftritt und damals keyd im Rahmen der Implementierung des usbkbd Plugin auf eine neue Version aktualisiert werden musste, habe ich mal das usbkbd Plugin installiert.
Und siehe da, das System fährt nach der Installation des usbkbd Plugin wieder ohne große Verzögerung herunter.

Verstehe ich das richtig, dass ich nur das usbkbd Plugin zusätzlich installieren muss, also keine weiteren Änderungen - und dann müsste er zumindest wieder ordentlich 'runterfahren? Du schreibst ja auch, dass als "Nebeneffekt" auch der HW-Powerknopf zum Shutdown führt. Klingt toll - ich teste gleich mal...

{später}
Der "Nebeneffekt" klappt immerhin: HW-Powerbutton funktioniert. ABER: NUR das usbkbd Plugin installieren ist/war wohl eine schlechte Idee, ich lande in einer Art Endlosschleife: mit jedem Start (Dienst VDR genügt) will er RCU-FB neu anlernen. Zwar werden angelernte Tasten in die /etc/vdr/remote.conf geschrieben, aber - in einer Endlosschleife. Und das, OBWOHL es eine /etc/vdr/remote.conf.d/RCU.conf gibt. Ich weiß nicht, ob das helfen würde, aber gaaanz früher gab es (meine ich) durch Ändern der Lade-Reihenfolge von Plugins die Möglichkeit das Verhalten zu beeinflussen.

Zum Splash: Nach der BIOS-Meldung kommt schon das MLD Logo und die (Grub-)Wartezeit wird 'runtergezählt. Das Zählen verschwindet, das Logo bleibt, er scheint zu booten. Pulsieren sah ich es nicht. "Irgendwann" wird kurz der Bildschirm grau und die drei Punkte kommen. Kurz darauf erscheint das OSD und er will die RCU-FB anlernen (siehe oben). Beim Runterfahren (Powerbutton oder auch F12) kommt erst die OSD-Meldung "Taste drücken um Ausschalten abzubrechen", nach ein paar Sekunden wird dann das Bild schwarz mit Logo (ich meine es auch pulsieren gesehen zu haben, das geht jetzt sehr schnell) und manchmal wird der Bildschirm grau und die Punkte kommen und manchmal schaltet er direkt ab.

Der Effekt "kein Ton" ist nun bedeutend häufiger. In den letzten Tagen  war es nur sporadisch, ich habe kein richtiges "System" erkennen können wann. Ich MEINE, es war, wenn ich nur PC-Neustart im WebIf  gewählt hatte, beim Einschalten war der Ton fast immer da.
Ich habe nun usbkbd ersmal wieder entsorgt 

EDIT: Verdammt, ich habe die Frage nach den Images übersehen. Ich habe zur Zeit das Intel-Image mit VAAPI - wie das mit den Punkten bei Intel-Image mit Softdevice war weiß ich nicht mehr und wie es bei dem "klassischen" Image mit Softdevice war schon gar nicht mehr. Da ich ja ohnehin vielleicht wieder zurück (von VAAPI weg) will taste ich das da auch gezielt.

Kann/darf es auf einem USB-Stick mehrere Backups (WebIf - Einstellungen - Backup) geben oder nur eines?

[rfehr]

Hi Purzel,

zum testen nutzte ich immer USB Sticks, um darauf unterschiedliche Version/Einstellungen/Plugins zu testen,
wenn ich dann alles passend habe instaliere ich das dann auf eine Festplatte/SSD, auf dem Produktiv System.

Gruß,
  Roland

[purzel]

Moin!

Danke Roland, das wäre sicherlich die bessere Idee gewesen - ich habe habe aber auch nicht damit gerechnet, bei meiner Neuinstallation (deswegen gibt es diesen Thread überhaupt) so viele Probleme zu bekommen 
Meine Frage mir den Backups ging jedoch in eine andere Richtung: Ich habe vor der Neuinstallation mein Testsystem auf einen Stick "gebackupt" (bäh, welch hässliches denglisch) und wollte nun - bevor ich testweise auf softhddevice zurück gehe - ein neues Backup machen. Hier ist es wohl schlauer, einen LEEREN Stick zu verwenden?

Ich habe heute leider zunächst andere Dinge zu tun, der VDR muss noch warten   

[clausmuus]

Zum usbkbd:
Bei dem gibt es ein besonderes Verhalten. Es werden nicht alle remote conf Dateien verwendet, sondern nur die usbkbd. Gesteuert wird das über ein usbkbd.sh (oder so ähnlich) im Ordner /ues/share/vdr/run.d . Der Grund ist, dass es ansonsten zu doppelten Tastendrücken kommt. Du müsstest das mal so anpassen, dass am Ende Diene remote.conf Datei hinzugefügt wird.

[clausmuus]

Backups kannst Du beliebig viele auf einen USB Stick packen und diese beliebig benennen. Das sind ja nur Zip Archive.

Auch wenn Du letztendlich doch das klassische x86'er Image mit softhddevice verwenden solltest, haben all Deine Versuche und Erkenntnisse dazu beigetragen die MLD noch ein Stück besser zu machen bzw. werden diese in nächster Zeit besser machen, wen diese zu Korrekturen/Änderungen führen.