[purzel]

Hallo Claus!

Vielen Dank für die Anleitung - das funktioniert. Da muss man erstmal drauf kommen 

Parallel habe ich "meinen" Weg mit dem remote-Plugin nochmal aufgegriffen. Vielleicht ist ja eine der beiden Vorgehensweisen noch für Andere hilfreich/brauchbar um z.B. Mäuse mit vielen Tasten oder andere Eingabegeräte ungleich den "Standards" (Tastatur, LIRC, XKeySym) benutzen zu können.
Dazu habe ich meine selbst erstellte /etc/vdr/remote.conf.d/remote-event6.conf nochmal gelöscht und das remote Plugin deinstalliert und den (Service) VDR neu gestartet. Im Anschluss habe ich bei laufendem VDR das remote Plugin erneut installiert; im WebIf erschien (erwartungsgemäß) die Aufforderung, VDR neu zu starten. OK, hab ich gemacht, bin ja manchmal folgsam
Zu meiner positiven Überraschung kam dann im OSD "Fernbedienung anlernen /dev/input/event6" - das war vorgestern aus irgendwelchen Gründen nicht der Fall. "Schau an" dachte ich mir und klickte die Maus links für Up, rechts für Down und Mitte für Menu - ab dann kann man ja speichern oder abbrechen - was ich auch tat. Ein Blick in die /etc/vdr/remote.conf bescherte

Code: [Select]

remote-event6.Up         0000000100010110
remote-event6.Down       0000000100010111
remote-event6.Menu       FFFFFFFC00020001Na prima - also nicht "BTN_UP" oder sowas sondern Hex-Werte. OK, dann also die. Die habe ich dann, weil auch dieses Anlernen keine automatische separate Datei in /etc/vdr/remote.conf.d/ erzeugte, selbst in eine solche verfrachtet:

Code: [Select]

remote-event6.Yellow         0000000100010110
remote-event6.Green          0000000100010111Und - tadaa - DAS funktioniert ebenfalls.

Nun "darf" ich mich entscheiden, welchen Weg ich besser finde  (Oder gibt's eine Art Empfehlung?

Da fällt mir ein: ich wollte ja noch vaapivideo testen...

[purzel]

Da fällt mir ein: ich wollte ja noch vaapivideo testen...

Waaahh! Jetzt geht gar nichts mehr!

Schon installiert war "intel-vaapi-driver". Ich habe dann "vdr-plugin-vaapivideo" installiert und schon ging nichts mehr. Sofort habe ich vdr-plugin-vaapivideo sofort wieder deinstalliert - und ... kein VDR mehr 
Nach einem reboot kommt anstatt TV Bild das Setup, als ob ich frisch installieren wollte und im WebIf unter Apps kein VDR. Interessanterweise ist auch  intel-vaapi-driver nicht mehr installiert. Es reicht aber nicht, (nur) das wieder zu installieren, es geht immer noch nicht wieder.
Leider gibt es kein automatisch angelegtes Snapshot "zwischen" vorgestern (Installation evtest) und der LETZTEN heutigen Installation (also die gerade eben) von intel-vaapi-driver.

In meiner Panik habe ich gedacht "OK, dann das Snapshot von vorgestern" und inzwischen zwei Mal neu gebootet - kein VDR 
Ich habe wohl mit dem Versuch  "vdr-plugin-vaapivideo" das System so schön zerschossen, dass ich von vorn abfangen muss 

Kann ich das Ding vielleicht doch noch retten? Kann ich nach irgendetwas sinnvollerem als "vdr" im Log filtern? Bei DEM Filter ist eine der letzten Meldungen
"Aug 22 14:52:57 MLD systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT"

F1! F1!

[franky]

Wirklich seltsam, dass auch der Snapshot von Vorgestern nicht mehr funktioniert.
Wurde der den wirklich zurückgespielt, oder gab es da eine Fehlermeldung?

Das Paket "intel-vaapi-driver" wird von softhddevice-intel benötigt, hat also nicht direkt was mit vaapivideo zu tun.
Das Paket "intel-vaapi-driver" enthält den alten i965 VAAPI Treiber.
Der wird aber von vaapivideo nicht benötigt, weshalb er bei der Installation von vdr-plugin-vaapivideo deinstalliert wird.
 
Wie hattest du vdr-plugin-vaapivideo eigentlich installiert?
Die sicherste Methode wäre vorher vdr-plugin-softhddevice-intel im WebIF über Paket-SUCHE zu deinstallieren.
Und anschließend vdr-plugin-vaapivideo zu installieren.

[purzel]

Wirklich seltsam, dass auch der Snapshot von Vorgestern nicht mehr funktioniert.
Wurde der den wirklich zurückgespielt, oder gab es da eine Fehlermeldung?

Eine Fehlermeldung gab's nicht, das von vorgestern hat den "Titel" "...before install evtest" - und das Zurückspielen muss (einigermaßen) geklappt haben - evtest ist nämlich nicht mehr da.

Wie hattest du vdr-plugin-vaapivideo eigentlich installiert?

Auch wen ich die folgende Formulierung selbst auch nicht mag wenn sie mir gegenüber jemand benutzt: "ganz normal, über's WebIf", also Pakete -> Suche -> vdr-plugin eingetippt -> vdr-plugin-vaapivideo angeklickt -> VDR Neustart. Resultat: Debakel 

Die sicherste Methode wäre vorher vdr-plugin-softhddevice-intel im WebIF über Paket-SUCHE zu deinstallieren.
Und anschließend vdr-plugin-vaapivideo zu installieren.

Für "vorher" ist es ja nun leider zu spät 

Wenn ich versuche, über's WebIf "Dienste" den VDR-Dienst zu starten kommt im OSD " '/dev/input/ir': No such file or directory" - Da kam ich auf die Idee, das Remote-Plugin nochmal wegzuwerfen - und nun läuft der VDR wieder. Anscheinend ist also (vgl. mein Posting von heute Vormittag) die Variante von Claus die Bessere.
"Leider" (naja, eigentlich nicht) habe ich 'ne Einladung uns muss mich nun beeilen...

[franky]

Auch wen ich die folgende Formulierung selbst auch nicht mag wenn sie mir gegenüber jemand benutzt: "ganz normal, über's WebIf", also Pakete -> Suche -> vdr-plugin eingetippt -> vdr-plugin-vaapivideo angeklickt -> VDR Neustart. Resultat: Debakel 

Ich habe dein Vorgehen gerade mal getestet und es funktioniert auch.
Ein VDR Restart nach dem Wechsel zu vaapivideo reicht aber nicht, da vorher der XServer beendet werden muss.
Besser ist da dann ein Reboot.
Das war aber nicht dein Hauptproblem.

Da kam ich auf die Idee, das Remote-Plugin nochmal wegzuwerfen

Das war dann vermutlich bei der Umstellung auf vaapivideo auch dein wirkliches Problem.
Ich habe vaapivideo zusammen mit dem remote plugin (verwende ich eigentlich nie) gerade getestet und hatte das gleiche Problem.
Da verträgt sich offenbar vaapivideo nicht mit dem remote Plugin.
Das könnte daran liegen, dass vaapivideo ohne XServer laufen muss, da es es zur Ausgabe DRM verwendet.

Evtl. könnte das auch Probleme mit dem rcu Plugin geben.

[purzel]

Moin!

Vielen Dank Franky!

Ich habe nun

Die sicherste Methode wäre vorher vdr-plugin-softhddevice-intel im WebIF über Paket-SUCHE zu deinstallieren.
Und anschließend vdr-plugin-vaapivideo zu installieren.

diese Variante probiert - mit "schrittweisem" Erfolg: nach Deinstallation von vdr-plugin-softhddevice-intel wollte er keinen (VDR-)Neustart, habe ich auch unterlassen. Anschließend habe ich vdr-plugin-vaapivideo installiert und (angeforderten) VDR-Neustart gemacht. Immerhin Bild, und auch ein neuer Menüeintrag "VAAPI Video" mit Unterpunkt "Mediaplayer" (noch ungetestet) aber kein Ton - schade eigentlich. Sämtliche Einstellungen im WebIf bzgl. Ton führten nicht zum Erfolg. Dann Reboot - und nun ist auch Ton. Hurra!
Allerdings, und das bedarf ausgiebigerer Tests - manchmal kurze Aussetzer. Angeblich, das fand ich zum Zeitpunkt "kein Ton" bei der Websuche, haben manche Leute wohl auch das Problem, dass der Ton nach einiger Zeit des Betriebs ausfällt und nicht wieder kommt...
Ob nun das Bild bei softhddevice oder vaapivideo besser ist... Hm, schwierig.
Aber - noch größeres Hurra - RCU funktioniert anscheinend auch - hoffentlich persistent. Für mich gilt wie gesagt: ohne RCU kein VDR 

Teste ich nun noch das remote-Plugin (wegen der Maustasten) oder verwende ich gleich die obige Variante von Claus? Dieses keyd Dingens scheint schon verdammt mächtig zu sein (lt. manpage). Aus dem Bauch heraus bin ich inzwischen bei Claus' Variante, aus zwei Gründen: sie erscheint Ressourcen-sparsamer zu sein (kein zusätzliches Plugin zu laden) und zweitens die "Angst" vor Nicht-Funktionieren aufgrund der gestrigen Erlebnisse...

Um eine andere Kleinigkeiten der vorigen Woche nochmal wieder aufzugreifen:

Seltsam übrigens, dass trotz deutschsprachigem VDR-OSD unter "System" die "Commands" alle auf englisch sind. Der empfohlene Weg dürfte sein, /etc/vdr/commands.conf.d/* anzupassen und ggf. zu ergänzen - richtig?

(ergänzen weil mir einige Punkte des damaligen setup fehlen)

[clausmuus]

Das snapshots fehlen, hat seit der MLD-6 noch kein User berichtet. Bei der MLD-5 kam das ja gelegentlich vor, aber bei der 6'er sollte der Fehler behoben sein. Und das ein zurück spielen eines Snapshots nicht klappt (bzw. den alten Stand nicht komplett wieder herstellt) gab es nur ganz selten mal bei der 5'er MLD, nach einem Kernel update. Das kann ich mir also auch nicht erklären.

Zu Deiner Frage mit den Commands: Ja, da ist das beste Vorgehen die Commands Datei anzupassen.
Übersetzungen gibt es in diesem Bereich nicht, da es sich um statische Dateien handelt, die nicht zur Laufzeit mit der passenden Sprache übersetzt werden. Das wäre zwar technisch möglich, aber doch recht aufwendig.

[purzel]

Hab Dank für die Bestätigung meiner Theorie mit dem Menü. Statische Dateien zu übersetzen kriege ich schon hin 

Das mit den Snapshots versuche ich weiter zu beobachten - vielleicht ergibt es sich wieder.

Ein weiteres Symptom, welches ich erst noch beobachten muss: entweder seit ich das vaapi Plugin nutze oder seit dem ersten (Test-)Timer habe ich den Eindruck, dass er deutlich länger zum 'runterfahren braucht. Das muss aber wie gesagt erst geprüft/verifiziert werden. Morgen oder so - meine "ToDoList" ist lang 

Die Test-Aufnahmen mit ZWEI Tunern waren übrigens erfolgreich! (War ja Premiere für mich)

[purzel]

Moin!

Das mit den Snapshots versuche ich weiter zu beobachten - vielleicht ergibt es sich wieder.

"Es geht schon los". Meiner Meinung nach müsste doch eigentlich ein Snapshot da sein von der deinstallation von vdr-plugin-softhddevice-intel gestern Vormittag - ist aber nicht; siehe Screenshot.

Ich würde nämlich gerne noch einmal zu softdevice zurück um zu sehen ob das die Zeit des Herunterfahrens beeinflusst...

... noch beobachten muss: entweder seit ich das vaapi Plugin nutze oder seit dem ersten (Test-)Timer habe ich den Eindruck, dass er deutlich länger zum 'runterfahren braucht. ...

... im Moment braucht er ~100 Sekunden (!) zum Herunterfahren. Links oben sind währenddessen drei Punkte auf dem Bildschirm. Was macht der da so lange? (Wenn meine Erinnerung nicht total daneben liegt ging das vorige Woche deutlich schnellerer)

Apropos 'runterfahren: wo und wie binde ich in der 6.x ein Shellscript ein, welches beim Herunterfahren ausgeführt werden soll?

[clausmuus]

Es hätte auch ein Snapshot existieren müssen, das vor Deinem wechsel auf den älteren Stand erstellt werden sollte.
Da ich im Moment keine Idee habe, warum bei dir das automatische erstellen der Snapshots nicht zuverlässig funktioniert, empfehle ich erst mal manuelle Snapshots zu erstellen, bevor Du größere Änderungen vornimmst.

Eventuell hilft es, wenn Du beim herunterfahren einmal die ESC Taste drückst. Dann sollten alle Logmeldungen angezeigt werden, und auch, auf welche Prozesse gewartet wird. Alternativ kannst Du beim Booten den Verbose Modus auswählen, das wirkt sich auch auf das herunterfahren aus.
Es kann Durchaus sein, dass ein VDR Plugin das Herunterfahren des Systems verlangsamt. Dies tritt z.B. auf, wenn dies sehr ausgiebige stop Aktionen durchführt, oder das Beenden des VDRs komplett blockiert. Allerdings würde ich so was eher beim EPG-Daemon vermuten, als beim vaapi Plugin.

[clausmuus]

Du kannst eigene Scripte z.B. unter /usr/share/vdr/shutdown.d ablegen, wenn es sich um VDR spezifische aktionen handelt, und dort auch steuern ob das herunterfahren unterbunden/verschoben werden soll.
Oder Du erstellst Dir einen eigenen systemd Service, den Du unter /etc/systemd/system ablegst, und rufst über den Dein Script auf. Dann kannst Du genau festlegen wann das ausgeführt werden soll.

[purzel]

Eventuell hilft es, wenn Du beim herunterfahren einmal die ESC Taste drückst. Dann sollten alle Logmeldungen angezeigt werden, und auch, auf welche Prozesse gewartet wird. Alternativ kannst Du beim Booten den Verbose Modus auswählen, das wirkt sich auch auf das herunterfahren aus.

EINmal Esc drücken reichte nicht, ich musste mehrmals drücken; verbose beim Start führte nicht zu ausführlichen Meldungen beim RUNTERfahren. Nach mehrmals Esc-Taste beim Runterfahren aber konnte ich ein bisschen sehen: Vieles wurde schnell gestoppt, bis einschließlich "MLD webIf". Danach kommt noch "A stop job is running for Foreground App" mit 'runterzählender Zeit. Nach über einer Minute dann kommen für Bruchteile von Nanosekunden noch irgendwelche Meldungen und dann schaltet er aus.

Es kann Durchaus sein, dass ein VDR Plugin das Herunterfahren des Systems verlangsamt. Dies tritt z.B. auf, wenn dies sehr ausgiebige stop Aktionen durchführt, oder das Beenden des VDRs komplett blockiert. Allerdings würde ich so was eher beim EPG-Daemon vermuten, als beim vaapi Plugin.

Du bist der Boss - aber der Effekt ist meiner Erinnerung nach erst seit Benutzen von VAAPI da. Kann es sein (so richtig gut bin ich in Sachen Systemd (noch) nicht), dass er den wegen VAAPI ohnehin nicht mehr laufenden X-Server versucht abzuschießen? (Bezug: /etc/systemd/system/multi-user.target.wants/appstarter.service und /usr/bin/appstarter.sh )
Ich probiere es vielleicht nochmal mit softhddevice. Snapshot nicht vergessen

Übrigens fährt er bei Drücken des Hardware-Powerknopf gar nicht runter. Warum nicht?

Du kannst eigene Scripte z.B. unter /usr/share/vdr/shutdown.d ablegen, wenn es sich um VDR spezifische aktionen handelt, und dort auch steuern ob das herunterfahren unterbunden/verschoben werden soll.
Oder Du erstellst Dir einen eigenen systemd Service, den Du unter /etc/systemd/system ablegst, und rufst über den Dein Script auf. Dann kannst Du genau festlegen wann das ausgeführt werden soll.

Das Script in  /usr/share/vdr/shutdown.d klappt - nachdem ich gefühlte 100 Mal über einen Tippfehler der das wirkungsvoll verhindert hat hinweg geschaut hatte  Mit Systemd habe ich mich wie oben erwähnt noch nicht nicht so richtig angefreundet 

[clausmuus]

Wenn ich mich richtig erinnere kann man in den Webif Settings auswählen, ob oder was der Powerbutton tut. Kann aber auch sein, das ich das da mal einbauen wollte

[franky]

Übrigens fährt er bei Drücken des Hardware-Powerknopf gar nicht runter. Warum nicht?

Das hatte ich auch schon bemerkt.
Es liegt an vaapivideo und daran, dass dann kein XServer läuft.

Bei softhddevice funktioniert das Ausschalten per Hardware-Powerknopf einwandfrei.
Bei laufendem XServer wird der PowerButton ausgewertet und das System fährt herunter.

[purzel]

Guten Morgen zusammen!

Ach ist das schwierig... 

• Mit VAAPI habe ich einen simplen funktionalen AV-Player, genau wie ich ihn mir wünsche und insgesamt zufriedenstellende Bildqualität - aber Tonaussetzer (besonders wenn frisch hochgefahren), mehr oder minder stark ausgeprägte Probleme beim Herunterfahren und (leicht verschmerzbares) Fehlen von HbbTV.
• Mit dem neuen Intel-Image habe ich theoretisch die beste Bildqualität und ordentliches Herunterfahren sowie anscheinend intakten Ton (Aussetzer wie oben würden ja sofort auffallen) - aber weder "intern" Mediaplayer noch MPV-Plugin und kein HbbTV (verschmerzbar).
• Mit dem "gewöhnlichen" Image (zumindest "halb alte" Version) habe ich zufriedenstellende Bild- und Tonqualität, (gewohntes) MPV-Plugin, ordentliches Herunterfahren und (theoretisch weil ungetestet) HbbTV - aber potentiell Probleme (noch keine bemerkt) mit meiner relativ modernen Intel-CPU/GPU N100.

Das sind jetzt zwar nur die auffälligsten weil in den letzten Tagen besonders beachteten Eigenschaften - aber ich sehe eine Tendenz: ab Besten bin ich anscheinend beim "gewöhnlichen" Image aufgehoben. Ich denke, ich mache vom jetzigen Zustand (Intel-Image und VAAPI) erstmal ein Backup, spiele das alte Backup von vor der Neuinstallation zurück und teste damit nochmal ausführlich - besonders, das waren ja die gravierendsten Neuerungen in meiner Neuinstalltion - Dual-Tuner-Betrieb und KEINE Aufzeichnungen auf der Systemplatte bzw. -SSD. Leider wirft mich die Aktion um eine Woche zurück 

Wenn ich mich richtig erinnere kann man in den Webif Settings auswählen, ob oder was der Powerbutton tut. Kann aber auch sein, das ich das da mal einbauen wollte

Es gibt die Einstellung "Power Taste - Wenn diese Option gesetzt ist, fährt das System sofort herunter, wenn die Power Taste am Gerät gedrückt wird, und die aktion wird nicht von der laufenden App behandelt." - aber weder die noch das neue Update des vdr-plugin-vaapi bewirken eine Verbesserung des Herunterfahrens. 

Kann es sein ..., dass er den wegen VAAPI ohnehin nicht mehr laufenden X-Server versucht abzuschießen? (Bezug: /etc/systemd/system/multi-user.target.wants/appstarter.service und /usr/bin/appstarter.sh )

Wäre da ein Ansatz?