Beiträge von seahawk1986

Du musst die PPAs für Ubuntu 22.04 in der group_vars/all bzw. besser deiner eigenen Kopie davon in der host_vars/localhost anpassen - also z.B.:

branch: jammy
ppa_owner: "ppa:seahawk1986-hotmail"
repositories:
  - '{{ ppa_owner }}/{{branch}}-main'
  - '{{ ppa_owner }}/vdr-2.6.6'
  - '{{ ppa_owner }}/{{branch}}-kodi'

Nachdem KODI das Aus für die PPAs verkündet hat (https://kodi.tv/article/ubuntu…i-ppa-officially-retired/), habe ich das Playbook im focal-Branch mal so erweitert, dass man optional KODI auch als flatpak nutzen kann, wenn man die Variable kodi_as_flatpak: True setzt: https://github.com/yavdr/yavdr…focal/group_vars/all#L106

Das Konfigurationsverzeichnis ändert sich von ~/.kodi zu ~/.var/app/tv.kodi.Kodi/data/ - Einstellungen und Datenbanken werden nicht automatisch kopiert bzw. übernommen.

Auf einem Testsystem hatte ich Probleme mit dem Start des RPC-Server (den die Systemd-Unit nutzt, um KODI sanft zu beenden), aber das konnte ich auf anderen Installationen nicht reproduzieren.

Zitat von obelix

Ich habe die host_vars/localhost von meinem VDR übernommen

Ich hatte da neulich etwas umgestellt, damit nicht bei jedem Durchlauf des Playbooks die Locale-Dateien neu generiert werden müssen - einfach wie in https://github.com/yavdr/yavdr…3374dab5827b39a3b1506f295 das " UTF-8" am Ende entfernen.

Es gibt da noch einen Patch für das Plugin aus RE: [vdr-plugin-control] Aktuelle Probleme von Zabrimus, den ich damals in die yaVDR-Pakete übernommen habe - ist der noch relevant?

Index: vdr-plugin-control-1.0.1/keyboard.c
===================================================================
--- vdr-plugin-control-1.0.1.orig/keyboard.c    2024-03-27 22:17:40.962662360 +0100
+++ vdr-plugin-control-1.0.1/keyboard.c 2024-03-27 22:17:40.954662470 +0100
@@ -75,7 +75,7 @@
  * cCtrlKeyboard
  ******************************************************************************/
 
-cCtrlKeyboard::cCtrlKeyboard(const char* name) : cKbdRemote() {
+cCtrlKeyboard::cCtrlKeyboard(const char* name) : cRemote("KBD") {
   mName = name;
   debug_plugin("'%s' = %p", mName.c_str(), this);
 }
Index: vdr-plugin-control-1.0.1/keyboard.h
===================================================================
--- vdr-plugin-control-1.0.1.orig/keyboard.h    2024-03-27 22:17:40.962662360 +0100
+++ vdr-plugin-control-1.0.1/keyboard.h 2024-03-27 22:17:40.958662415 +0100
@@ -12,7 +12,7 @@
 /*******************************************************************************
  * cCtrlKeyboard
  ******************************************************************************/
-class cCtrlKeyboard : public cKbdRemote  {
+class cCtrlKeyboard : public cRemote  {
 private:
   std::string mName;
 public:
Index: vdr-plugin-control-1.0.1/telnet.c
===================================================================
--- vdr-plugin-control-1.0.1.orig/telnet.c      2024-03-27 22:17:40.962662360 +0100
+++ vdr-plugin-control-1.0.1/telnet.c   2024-03-27 22:17:40.958662415 +0100
@@ -402,9 +402,6 @@
 
 
 void cCtrlGateway::Action() {
-  /* NOTE: DO NOT DESTROY 'kbd', VDR ITSELF DESTROYS IT.
-   * Otherwise double free on exit of vdr.
-   */
   cCtrlKeyboard* kbd = new cCtrlKeyboard("cCtrlKeyboard");
   cOsdState osdstate(this, "cOsdState");
 
@@ -479,6 +476,8 @@
      } // while mActive
   } while(0);
 
+  Remotes.Del(kbd, true);
+
   debug_plugin("gateway thread ended (pid=%d)", getpid());
 }

Was genau heißt, dass der Speicher sich unterscheidet? Meinst du die Zahl der erkannten RAM-Riegel oder die Auslastung von Arbeitsspeicher und Swap (free -h)oder etwas anderes?

Zitat von wofritz

Ich habe in /etc/X11/xorg.conf die Section InputClass auskommentiert, wie Gsus sagt, aber das kann doch nichts bewirken da ja eventlircd ohnehin gestoppt ist.

Damit hast du ggf. das Problem, dass eventlircd das Gerät für die Fernbedienung nicht exklusiv öffnen kann - und dann funktioniert die im VDR nicht bzw. höchstens für die Frontends, die ebenfalls Events verarbeiten, die vom X-Server kommen, was dann im dümmsten Fall zu doppelten Tastendrücken führen kann.

Zitat von wofritz

Nun wird eventlircd nicht gestoppt, nur irexec (muss vielleicht nicht sein) und irxevent gestartet.

Solange du keine Fernbedienungstasten in irxevent nutzen willst, die bereits von irexec belegt sind, muss das nicht gestoppt werden.

Zitat von wofritz

Wie kriege ich es nun noch hin, dass das Frontend detached bleibt?

Regelhaft funktioniert das so, dass man frontend-dbus-send switchto $FRONTEND (bzw. die entsprechende DBus-Methode von yavdr-frontend - ich hatte schon mal ein bisschen Dokumentation dazu geschrieben, das deckt aber noch nicht alles ab: https://gist.github.com/seahaw…5296f4175ca85eda4bc6cd449) aufruft (wobei $FRONTEND der Name einer .desktop-Datei (in dem Fall wird die über die /usr/lib/systemd/user/app@.service gestartet und nachverfolgt) oder einer anderen Systemd-Unit in der User-Session für den Nutzer vdr sein kann), vom aktuell als Ausgabe gesetzten Programm zu einem anderen Programm zu wechseln. Dann weiß das Frontend-Skript, dass es das zuvor aktive Frontend nicht wieder aktivieren soll, bis diese Systemd-Unit wieder beendet wurde bzw. man ihm sagt, dass es zurück schalten soll.

Also angenommen die Ausgabe über ein VDR-Frontend ist gerade aktiv und man führt frontend-dbus-send switchto firefox aus.

Das führt dazu, dass das aktuell aktive VDR-Frontend beendet wird, der VDR nicht mehr auf die Fernbedienung reagiert (passiert über das dbus2vdr Plugin - das macht im Prinzip das selbe wie ein svdrpsend remo off) und da es standardmäßig keine firefox.service Unit für die User-Session gibt, wird app@firefox.service in der Systemd User Session des Nutzers VDR gestartet, das die Informationen aus der /usr/share/applications/firefox.desktop nutzt, um den Firefox zu starten.

Systemd übernimmt dann die Aufgabe den Status des von ihm gestarteten Prozesses zu tracken und das yavdr-frontend lauscht auf dessen DBus-Signale, die etwaige Statusänderungen für die Systemd-Unit weitergeben. Wenn die Systemd-Unit ihren Status auf stopped wechselt, reaktiviert das yavdr-frontend Skript das VDR-Frontend und lässt den VDR wieder auf die Fernbedienung reagieren (analog zu svdrpsend remo on).

Ansonsten kann man mittels frontend-dbus-send toggle_noninteractive auch das gerade aktive Frontend stoppen und das yavdr-frontend reagiert nicht auf Tastendrücke auf der Fernbedienung, um das Frontend wieder zu starten, bis man das es über frontend-dbus-send toggle_noninteractive, frontend-dbus-send toggle oder frontend-dbus-send start wieder anschaltet.

Ich habe es mal eingebaut und dabei die USB- und PCI-IDs in eigene Listen gepackt, damit das im Playbook nicht in lange oder-Verkettungen ausartet.

Zitat von wofritz

Wo liegt der Fehler?

Ich würde vermuten, dass der Firefox nichts mit den Sachen anfangen kann, die das externalplayer-Plugin an ihn schickt, weil der nicht wie mplayer funktioniert, sondern so ausgelegt ist, dass er die Events nur vom X-Server bekommt.

Eine Möglichkeit das bei yavdr-ansible zu lösen, wäre über das yavdr-frontend eine Systemd-Unit für die Ausgabe zu starten, die zusätzlich zum Firefox auch noch irxevent mit startet und dann aus den Tastendrücken, die von eventlircd kommen, Eingaben generiert, die von Clients des X-Server gesehen werden können - in [gelöst] [yavdr-ansible] Fernbedienung in Anwendungen nutzen (Firefox, Higan etc. pp.) hat sich Gsus eine Lösung erarbeitet, wie das funktionieren kann.

dile updated packages are currently building in the PPAs

Laut https://www.linuxtv.org/wiki/i…dHD_(DVB-T/T2/C)#Firmware braucht die Karte eine Firmware. Wenn du mir die PCI-ID gibst (da wäre die Ausgabe von lspci -nn für die Karte relevant), kann ich das ins Playbook einbauen, dass er die Firmware automatisch herunterlädt.

Für den SMT32-Empfänger sollte yavdr-hardware-irmp installiert worden sein, wenn eine bekannte USB-ID erkannt wurde (1209:4444 oder 16c0:27d9 - falls das nicht der Fall ist, bitte die Ausgabe von lsusb posten).

Für die SMT32-Variante, die den Empfänger nicht als Tastatur registriert, sondern die Tastendrücke über irmplircd ausliest, braucht es dann noch eine Keymap, die die von IRMP erzeugten Tastencodes auf die von yaVDR erwartete Tastenbelegung übersetzt (https://www.yavdr.org/document…tion.html#yavdr-namespace - relevant sind die KEY_* Namen in der Tabelle) - mittels sudo irw /var/run/lirc/irmplircd solltest du die Codes sehen können - die Zuordnung schreibst du dann in eine /etc/irmplircd/irmplicd.map - also z.B. sowas:

0250af00f200 KEY_UP
0254ab002c00 KEY_RIGHT

Für die STM32 Variante, die als Tastatur arbeitet, muss die Zuordnung von IR-Codes zu Tastennamen soweit ich weiß über die Konfigurationssoftware erfolgen - und dann kann man die Tastennamen bei Bedarf noch über eine evmap für eventlircd abändern - die udev-Regeln aus dem Paket yavdr-remote sollten /etc/eventlircd/evmaps/STM32_IRMP.evmap dafür konfigurieren (vgl. https://github.com/yavdr/yavdr…ventlircd-names.rules#L54), wenn ein entsprechend benannter Empfänger erkannt wurde.

Das sagt ja nur, dass yavdr-frontend nichts vom X-Server weiß (und es muss in der Sitzung des Nutzers vdr laufen, damit es wie gedacht funktionieren kann).

Hast du da noch etwas mehr Kontext dazu? Das sieht irgendwie danach aus, dass der yavdr-frontend Prozess nicht läuft.

Da bin ich gespannt - auf meinem nvidia-Testsystem kann ich das KODI aus den Ubuntu-Quellen über das yavdr-frontend Skript starten und wieder beenden.

Edit: dafür scheint das udiskie aus den Ubuntu-Quellen ein Problem zu haben.

Was für eine Fernbedienung nutzt du an dem System? Ich habe es gestern nur mal kurz mit einer Hama MCE Remote probiert, was problemlos ging - also sollte zumindest eventlircd funktionieren.

Zitat von wofritz

Ist das so gedacht?

Ja, die Power-Taste soll das System ausschalten - und das passiert über den vom VDR ausgelösten Shutdown, wenn keine Abbruchbedingung existiert. Das Frontend-Skript bittet dann den VDR alle paar Minuten darum einen Shutdown zu machen. Wenn man es sich anders überlegt und eine Taste drückt, wird das Programm, das zuletzt die aktive Ausgabe war, wieder gestartet.

Wenn du willst, dass die Power-Taste zurück zum VDR schaltet, kannst du das in dein Einstellungen des yavdr-frontend (

/etc/yavdr-frontend/config.yml

) vorgeben, vgl.: RE: ansible KODI beenden per Fernbedienung funktioniert nicht/endet mit Crash)

xterm forkt nicht beim Start (und mit ein bisschen extra Konfiguration verhält sich das auch recht brauchbar), das gnome-terminal hingegen zieht da einige Sonderlocken über DBus ab - wenn man es mit dem Parameter --wait startet, dann sollte es sich korrekt verhalten.

Das Menü wird vom vdr-plugin-desktop erzeugt und sortiert die Apps gemäß der damals von GNOME übernommenen gnome-applications.menu ein: https://github.com/flensrocker…r/gnome-applications.menu

Wenn man einen Menüeintrag auswählt, dann wird das start-Skript /var/lib/vdr/plugins/desktop/starter mit dem Pfad zur .desktop Datei für den Menüeintrag aufgerufen. Bei yavdr-ansible ist das so vorkonfiguriert (https://github.com/yavdr/yavdr…sktop/tasks/main.yml#L132 ff.), dass das Frontend-Skript darauf hin das laufende Programm beendet und das andere Programm startet und wenn das Programm beendet wurde automatisch wieder zurückschaltet.

OOTB funktioniert das nur für Anwendungen, die nicht forken und sich auf ein SIGTERM hin sauber beenden, sonst braucht es eine Systemd-Unit, die die Prozesskontrolle so abstrahiert, dass klar ist, wann sich ein Programm beendet hat - deswegen installiert das Paket python3-yavdrfrontend z.B. eine entsprechende Systemd-Unit für kodi, damit das über seine JSON-RPC Schnittstelle den Befehl bekommt sich zu beenden.

Wenn man das Plugin nur als einfachen Programmstarter nutzen will, ohne dass das Frontend-Skript versucht zwischen zwei Programmen umzuschalten, kann man z.B. das Beispiel-Skript aus den Plugin-Sourcen nutzen: https://github.com/flensrocker…b/master/examples/starter

Das hatte ich doch gestern angepasst: https://github.com/yavdr/yavdr…ibrary/xrandr_facts.py#L1

Murry: da sind wohl einige Pakete darüber gestolpert, dass Systemd-Dateien im Paket doppelt installiert wurden (sowohl von dh_installsystemd als auch über eine install Datei - ich habe das mal im noble-main PPA für die Pakete behoben, die vom Playbook installiert werden - das Playbook (ohne die Rolle yavdr-network) konnte ich mit dem aktuellen Git-Stand schon in einer VM erfolgreich durchlaufen lassen - momentan muss man nur noch diese Zeile mit dem warn entfernen, weil neuere Ansible-Versionen das nicht mehr unterstützen: https://github.com/yavdr/yavdr…es/dvd/tasks/main.yml#L26 - da muss ich mir noch ansehen, was das auf einem focal-System für Auswirkungen hat.

kfb77: bei meinen Ubuntu 24.04 Server und Desktop Installationen, die ich bislang in VMs gemacht habe, wurde ich bislang immer gefragt, welche Dienste ich neu starten will - nutzt du da eine Minimalinstallation oder ähnliches?

Zitat von Murry

Jetzt fehlt : vdr-plugin-dbus2vdr

Das ist aber im PPA, soweit ich das sehen kann:

$ apt policy vdr-plugin-dbus2vdr
vdr-plugin-dbus2vdr:
  Installiert:           (keine)
  Installationskandidat: 20211130143000experimental-0yavdr13~noble
  Versionstabelle:
     20211130143000experimental-0yavdr13~noble 500
        500 https://ppa.launchpadcontent.net/seahawk1986-hotmail/vdr-2.6.6/ubuntu noble/main amd64 Packages