Beiträge von seahawk1986

    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?

    Jetzt fehlt : vdr-plugin-dbus2vdr

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

    Code
    $ 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

    Ok, das war das Problem, dass Launchpad Pakete nicht annimmt, wenn man sie vom pbuilder signieren lässt, statt das mittels dpkg-buidpackage -S -sa -d zu erledigen. Die beiden Pakete sind unterwegs.

    Du kannst unter focal auch andere VDR-Versionen nutzen - da gibt es reichlich PPAs von mir auf Launchpad: https://launchpad.net/~seahawk1986-hotmail bis hin zum vdr-2.6.6 - einfach das neue PPA hinzufügen und danach das bislang für den vdr genutzte PPA mittels ppa-purge entfernen (https://wiki.ubuntuusers.de/Pa…eischalten/PPA/#PPA-Purge). Dann noch das Playbook anpassen, damit das auch das neue PPA nutzt, falls man es nochmal laufen lassen will.

    lircd2uinput fehlt auch noch - Launchpad akzeptiert bei beiden die Source-Pakete nicht, obwohl die von pbuilder lokal ohne Probleme gebaut werden können - das muss ich mir noch mal genauer ansehen.

    Start aus PowerOff: --> häufig schwarzes Bild (Ton läuft) / lässt sich teilweise nur durch vdr-restart (Blindbedienung bei schwarzem Bild) beheben

    Was steht dabei im Log? Lässt du den VDR auf die DVB-Tuner warten?

    top - 15:23:13 up 22 min, 1 user, load average: 0,35, 0,88, 0,92 Tasks: 153 gesamt, 1 laufend, 152 schlafend, 0 gestoppt, 0 Zombie %CPU(s): 1,3 be, 5,3 sy, 0,3 ni, 90,3 un, 0,1 wa, 0,0 hi, 2,6 si, 0,0 st

    Scheint arg hoch zu sein (kann aber an genutzten Plugins und sonstiger Software liegen) - mein ION-System sitzt das im TV-Betrieb (ohne Sachen wie epg2vdr oder epgsearch, die bei Aktualisierungen einiges an Rechenaufwand erzeugen können) auf einer Backe ab (DF1 HD ist der einzige unverschlüsselte Full HD Kanal hier im Kabel):

    Der TechnoTrend USB Empfänger (Treiber ttusbir) wird nicht automatisch erkannt. Ich finde allerdings auch keinen Eintrag, um eine Zeile in die rc_maps.cfg einzutragen --> Das entsprechende Template editiert, was aber nicht "systemkonform" ist.

    Listet irkeytable den den Empfänger?


    Die Datei wird aus dem Template https://github.com/yavdr/yavdr…/templates/rc_maps.cfg.j2 generiert - das genutzte Template-System hat sich sein yaVDR 0.6 durch die Nutzung von Ansible merklich geändert. In den Kopfzeilen einer Datei steht das jeweilige Template, aus der eine Datei generiert wurde, wenn es eine Konfigurationsdatei ist, die das Playbook bei weiteren Durchläufen wieder überschreiben würde - auf meinem ION-System sieht das z.B. so aus:

    Code
    $ head -n4 /etc/rc_maps.cfg
    #
    # *** ANSIBLE MANAGED FILE ***
    # template: /srv/files/alexander/alexander/yavdr-ansible/roles/yavdr-remote/templates/rc_maps.cfg.j2
    #


    Soweit ich das sehen kann, gibt es im Paket yavdr-remote noch keine keymap und Eintrag für die ttusbir - wenn du da eine Konfiguration vorschlagen kannst, kann ich die gerne einbauen.

    Aber wenn der vdr sich ausschaltet, startet er gleich wieder neu (in einer Schleife, ich hatte unter System/Sonstiges die Inaktivität reduziert auf ich glaube 10min von 300min (damit war der Schlaf sehr selten natürlich).

    Hat er denn einen Grund gleich wieder aufzuwachen?

    • USB-Geräte
    • WOL (je nach Einstellung kann schon an den Rechner gerichteten Traffic reichen, da muss nicht zwingend ein Magick Packet gesendet werden)
    • Wie sehen die Vorlaufzeiten für Timer usw. aus?

    Woran könnte das liegen, dass der Wakeup funktioniert, aber vom vdr aus das Setzen der Timer nicht? Steht das, was der vdr als Wakeup-Alarmzeit einträgt, in irgendeinem Log?

    Der VDR gibt die gewünschte Wakeup-Zeit über einen Shutdown-Hook an das vdr-addon-acpiwakeup weiter. Das sieht man normalerweise im Log - z.B.:

    Code
    Mär 02 21:24:28 vdr vdr[13321]: [13321] executing '/usr/lib/vdr/vdr-shutdown.wrapper 1709448480 37412 23 "Neue Geschichten vom Pumuckl~Eder ist an allem schuld" 0'
    Mär 02 21:24:28 vdr vdr[13321]: [13321] saved setup to /var/lib/vdr/setup.conf
    Mär 02 21:24:28 vdr vdr-addon-acpiwakeup[15217]: Writing 0 to /sys/class/rtc/rtc0/wakealarm
    Mär 02 21:24:28 vdr vdr-addon-acpiwakeup[15219]: Writing +37112 (for 1709448180) to /sys/class/rtc/rtc0/wakealarm
    Mär 02 21:24:28 vdr vdr-shutdown[15220]: executing /usr/share/vdr/shutdown-hooks/S90.custom as shell script

    Der VDR ruft den Shutdown-Wrapper mit den Argumenten für den nächsten Aufweckzeitpunkt auf - das vdr-addon-acpiwakup schreibt zunächst eine 0, um den vorhandenen Weckzeitpunkt zu löschen und mit der nächsten Schreibaktion gibt es an, wie weit der nächste Aufweckzeitpunkt in der Zukunft liegen soll.

    Muss ich dazu verm. zuerst den vdr stoppen ? : service vdr stop

    Es gibt mehrere Möglichkeiten: entweder du startest den VDR aus gdb heraus (funktioniert am besten, wenn der VDR die Startparameter aus dem ARGSDIR selber einliest, sonst rackert man sich da schnell mit langen Befehlen ab) oder du attachest gdb nachträglich an den laufenden VDR-Prozess.


    Mit systemd-coredump kann Systemd automatisch Backtraces erzeugen, wenn etwas crasht und man kann sich die später bequem mit Hilfe von coredumpctl anzeigen lassen.

    1. eventlircd läuft; mit oder ohne Flirc Stick.

    Also kommen die Tastatur Codes von /dev/input/event3 über irgend eine Tabelle in /etc/eventlircd/xxx.evmap zum VDR. Nur wie kann ich herausbekommen, welche evmap genommen wird? Muss ich eine eigene '03_046d_404d.evmap' erstellen (für eine Logitech K400+)?

    Man kann über eine udev-Regel durch das Attribut ENV{eventlircd_evmap} festlegen, welche evmap für ein Gerät genutzt wird.

    Spielt dann überhaupt die /var/lib/vdr/remote.conf eine Rolle?

    Ja - wobei es dann nicht der Teil für XKeySym Tasten ist, sondern die Tasten für LIRC (da eventlircd einen Lirc-kompatiblen Sockel bereitstellt, von dem der VDR liest)

    Und wie bekomme ich heraus, welche Udev-Parameter meine Tastatur hat?

    udevadm info kann dir auflisten, wie udev das Gerät sieht - z.B.:

    Code
    sudo udevadm info --query=all --attribute-walk --name=/dev/input/event4


    2. Wenn die Standard Templates unter ~/yavdr-ansible/roles liegen und ich kein Programm 'process-template' habe, funktioniert das ganze Template-System dann überhaupt noch, oder muss man die installierten Config-Dateien wie remote.conf direkt ändern?

    Die remote.conf ist ein Spezialfall, weil die vom VDR nachträglich verändert werden kann (wenn der den Anlern-Dialog startet - was nur geht, wenn das Frontend mit dem VDR gestartet wird, was standardmäßig mit Xorg-Ausgabe bei yaVDR nicht der Fall ist) - das ansible-Playbook expandiert das Template dafür nur, wenn die Datei noch nicht existiert.

    3. Wo muss ich eingreifen, damit ich im VDR die Default-Tastatur-Belegung des VDR wieder habe (z.B. m für Menü)?

    In der remote.conf - http://vdr-wiki.de/wiki/index.…BCr_vdr-sxfe_und_vdr-fbfe hat da z.B. eine Auflistung der alten Belegung.


    4. Mir ist auch aufgefallen, dass im VDR keine Maus (als Touchpad der Tastatur) läuft. Warum nicht?

    Die Ausgabeplugins werten Mauseingaben nicht aus.


    5. Kann das Ansible-Script oder einzelne Rollen davon schadlos wiederholt laufen, oder lieber nicht?

    Ja, Ansible ist dafür gedacht, dass man das System in einen in den Rollen definierten Zustand bringen kann - man kann das Skript beliebig oft laufen lassen.

    Soweit es geht versuche ich die Pakete für Ubuntu 20.04 aktuell zu halten (solange Launchpad es erlaubt dafür Pakete hochzuladen) - https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.6.6 deckt alles von focal bis noble ab - wenn du darauf umstellen willst: PPA hinzufügen, altes PPA mittels ppa-purge entfernen (https://wiki.ubuntuusers.de/Pa…eischalten/PPA/#PPA-Purge), dann sollte die Paketverwaltung alles gerade ziehen.


    Statt vdr-plugin-markad solltest du das neuere und noch gepflegte vdr-plugin-markad-ng nehmen. Das selbe gilt für das vdr-plugin-live-ng.


    Für ein Release-Upgrade werden die eingebundenen PPAs vorübergehend deaktiviert und ggf. Pakete deinstalliert, die nicht in den Ubuntu-Quellen sind und Abhängigkeiten haben, die nicht aufgelöst werden können. Da müsstest du dann nach dem Upgrade händisch etwas aufräumen. Nachdem firefox unter Ubuntu 22.04 nur noch als Snap zur Verfügung steht, muss das Benutzerverzeichnis des Users vdr in /home/ liegen, sonst lässt sich der Browser nicht starten - da könnte man ggf. mit den mittlerweile von Mozilla angebotenen Debian-Paketen drum herum arbeiten - vgl. https://linuxnews.de/mozilla-s…ository-fuer-firefox-vor/