[yavdr_ansible] diverse Kleinigkeiten

  • Moin zusammen,


    nachdem ich nun erste Gehversuche mit dem neuen yavdr ansible gemacht habe, versuche ich nun die restlichen Ungereimtheiten aus dem System zu bekommen.

    Diverse Dinge aus diesem Post sind bereits erledigt, aber um den dortigen Thread nicht zu unübersichtlich zu machen, fasse ich das Ganze hier mal zusammen.


    Eventuell hat ja schon jemand die eine oder andere Lösung zur Hand...


    1. beim Booten zeigt Grub error: no video mode selected

    Weder ein Setzen von GRUB_GFXMODE und GRUB_GFXPAYLOAD in /etc/default/grub noch ein Auskommentieren/Verändern von GRUB_HIDDEN_TIMEOUT und GRUB_HIDDEN_TIMEOUT_QUIET schafft Abhilfe


    2. nach dem Login bekomme ich die Meldung => There is 1 zombie process.

    Code
    ✔ ~/install/yavdr-ansible [bionic|…4] 
    09:14 # ps -ef | grep -i defun
    root      1159  1154  0 07:22 ?        00:00:00 [uname] <defunct>
    root      6840  4810  0 09:14 pts/1    00:00:00 grep --color=auto -i defun
    
    ✔ ~/install/yavdr-ansible [bionic|…4] 
    09:14 # ps -ef | grep 1154
    root      1154     1  0 07:22 ?        00:00:00 /usr/sbin/lircd --nodaemon
    root      1159  1154  0 07:22 ?        00:00:00 [uname] <defunct>
    root      6881  4810  0 09:14 pts/1    00:00:00 grep --color=auto 1154

    Die Fernbedienung funktioniert allerdings einwandfrei.


    3. der angeschlossene Zweitmonitor für osd2web geht nach einiger Zeit in den Stromsparmodus (blank screen)




    Folgende Punkte sind bereits erledigt, aber hier nochmal der Vollständigkeit halber erwähnt:


    4. Aufnahmeverzeichnis per NFS lässt sich beim Booten nicht einbinden


    Lösung: anscheinend funktionieren die systemd-eigenen Parameter xsystemd.automount, x-systemd.after=cloud-init.target zum Einhängen eines NFS-Mount nicht sauber, denn entweder bekomme ich ein network not available oder das System bleibt mit einem unendlichen Timeout beim Mount dieser Freigabe hängen. Schlussendlich habe ich den Mount aus der fstab in ein separates systemd-Script ausgelagert und per systemctl enable srv-vdr-video.mount aktiviert.



    5. Bei der Installation werden TV (an HDMI) und Infodisplay (an DVI) zwar erkannt, allerdings wird das Livebild auf dem Zweitmonitor angezeigt


    Lösung: anscheinend kommt die automatische Erkennung mit den Geräten durcheinander, da beide jeweils 1920x1080 unterstützen

    Lege ich in den host_vars die Reihenfolge der Geräte fest, passiert das nicht mehr.

    Code
    host_vars/localhost.yml:
    preferred_outputs: ["HDMI", "DVI", "DP", "VGA", "TV"]


    6. ansible bleibt bei der ersten Installation am Punkt lirc/eventlircd mit einem Fehler hängen


    Lösung: service eventlircd stop und install-yavdr.sh neu starten


    Für Tips bezüglich der offenen Punkte bin ich sehr dankbar.


    Cheers,

    Ole

    2 Mal editiert, zuletzt von OleS ()

  • 1. beim Booten zeigt Grub error: no video mode selected

    Weder ein Setzen von GRUB_GFXMODE und GRUB_GFXPAYLOAD in /etc/default/grub noch ein Auskommentieren/Verändern von GRUB_HIDDEN_TIMEOUT und GRUB_HIDDEN_TIMEOUT_QUIET schafft Abhilfe


    Hi,


    bei mir hat geholfen:

    Code
    chmod a-x /etc/grub.d/05_debian_theme
    update-grub
  • 3. der angeschlossene Zweitmonitor für osd2web geht nach einiger Zeit in den Stromsparmodus (blank screen)

    Probier mal, ob diese Änderung dagegen hilft (git pull für das Playbook im bionic-Branch machen und das Playbook noch mal laufen lassen): https://github.com/yavdr/yavdr…cee3daf9138918ebb471f0cdd

    Lösung: anscheinend funktionieren die systemd-eigenen Parameter xsystemd.automount, x-systemd.after=cloud-init.target zum Einhängen eines NFS-Mount nicht sauber

    Wie kommst du auf cloud-init.target? Das Target für eine konfigurierte Netzwerkverbindung ist network-online.target.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • chmod a-x /etc/grub.d/05_debian_theme

    Werde ich testen, vielen Dank schon mal für den Hinweis.


    Probier mal, ob diese Änderung dagegen hilft

    Ist eingebaut, jetzt muss ich nur wieder in der Nähe des Gerätes sein.


    Wie kommst du auf cloud-init.target?

    Weil die Vergabe der IP in /etc/netplan/50-cloud-init.yaml konfiguriert ist, ich davon ausgegangen bin, dass dies dann das richtige target ist und weil network-online.target nicht funktioniert - da bekomme ich beim Booten wieder network unreachable. :)


    Cheers,

    Ole

  • Noch ein kleines Problem:

    Fahre ich die Hardware mittels poweroff auf der Shell runter, wird die nächste Aufwachzeit nicht gesetzt, vermutlich wird also vdr-shutdown nicht ausgeführt.


    Cheers,

    Ole

  • Fahre ich die Hardware mittels poweroff auf der Shell runter, wird die nächste Aufwachzeit nicht gesetzt, vermutlich wird also vdr-shutdown nicht ausgeführt.

    Das funktioniert bislang wie bei bisherigen yaVDR-Versionen - die Shutdown-Hooks des vdr-addon-acpiwakeup werden nur ausgeführt, wenn der VDR den Shutdown initiiert - also könnte man z.B. sowas nehmen, wenn man per SSH am VDR hängt: svdrpsend hitk power && exit


    mini73 hat die Möglichkeit geschaffen den nächsten Aufwachzeitpunkt (unter Berücksichtigung der durch Plugins gesetzte Aufwachzeiten) über dbus2vdr abzufragen - das geht mit vdr-dbus-send /Shutdown shutdown.NextWakeupTime. Ich habe noch auf der TODO-Liste das vdr-addon-acpiwakeup durch acpiwakeup-ng zu ersetzen, damit ist es einfacher zusätzliche Hooks von KODI oder beim Beenden von Systemd-Units zu nutzen.


    Ich hoffe, dass ich über Pfingsten mal wieder ein bisschen Zeit für yaVDR habe.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dann habe ich das auf meinem Altsystem vorher wohl fehltinterpretiert, weil die Aufwachzeit eh schon vorher gesetzt war.

    acpiwakeup-ng hört sich gut an, dann warte ich mal gespannt. :)


    Ich hoffe, dass ich über Pfingsten mal wieder ein bisschen Zeit für yaVDR habe.

    Nur keinen Stress, bisher läuft der yavdr-ansible richtig gut und ich bin mal wieder auf einem aktuellen Stand. :tup


    Cheers,

    Ole

  • Dann habe ich das auf meinem Altsystem vorher wohl fehltinterpretiert, weil die Aufwachzeit eh schon vorher gesetzt war.

    Das könnte ein Nebeneffekt von den ConfirmShutdown-Aufrufen des Frontend-Skripts über dbus2vdr sein, dabei werden die Shutdown-Hooks auch ausgeführt, wenn man den Shutdown-Hooks Wrapper von dbus2vdr aktiviert (was bei yavdr-ansible IIRC noch nicht der Fall ist, weil ich das lifeguard-Addon noch durch lifeguard-ng ersetzen will, damit man auf den Shutdown-Wrapper von dbus2vdr verzichten kann (das ist als Paket vdr-addon-lifeguard-ng schon im PPA).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 1. beim Booten zeigt Grub error: no video mode selected

    Weder ein Setzen von GRUB_GFXMODE und GRUB_GFXPAYLOAD in /etc/default/grub noch ein Auskommentieren/Verändern von GRUB_HIDDEN_TIMEOUT und GRUB_HIDDEN_TIMEOUT_QUIET schafft Abhilfe

    Ich habe gerade ein Testsystem mit einem Athlon 64 3000+ und einer G210 aufgesetzt, ich sehe die Meldung nicht und sogar plymouth ist normal zu sehen.

    2. nach dem Login bekomme ich die Meldung => There is 1 zombie process.

    Bei mir wird da der lircd_helper als Zombie angezeigt:

    Code
    $ ps -ef | grep -i defun
    root       583   391  0 10:12 ?        00:00:00 [lircd_helper] <defunct>

    - da muss ich mir noch was für das eventlircd-Paket überlegen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • servus miteinander,


    die meldung "no video mode selected" hab ich hier auch, hat aber wohl keine negativen auswirkungen.


    hab eine andere baustelle, weiss zwar nicht, ob es hierher passt, betrifft ḿenuorg.

    folgende eintraege aus der vorgaenger-yavdr klappen nicht mehr:


    Code
    <command name="VDR neu starten" confirm="yes" execute="sudo /sbin/initctl restart vdr"/>
    <command name="Rechner neu starten" confirm="yes" execute="/usr/bin/at now -M -f /usr/bin/vdr-reboot"/>


    initctl laesst sich einfach durch systemctl ersetzen, im log kommt dann folgende meldung

    Code
    hu vdr: [1022] confirm: VDR neu starten?
    hu vdr: [1022] warning: VDR neu starten?
    hu vdr: [1022] confirmed
    hu vdr: [1022] executing command 'sudo /bin/systemctl restart vdr'
    hu vdr[1022]: sudo: no tty present and no askpass program specified


    gruss

    beinhart

  • initctl laesst sich einfach durch systemctl ersetzen, im log kommt dann folgende meldung

    Für initctl gibt es bis yaVDR 0.6 es einen Eintrag in der /etc/sudoers.d/yavdr, der die Passwort-Abfrage für den Befehl abschaltet: https://github.com/yavdr/yavdr…c/sudoers.d/yavdr/10_main - ich finde das aber nicht gut, wenn ein normaler User systemctl mit beliebigen Argumenten aufrufen darf...


    /usr/bin/vdr-reboot gibt es bei yavdr-ansible nicht (die richtige Reihenfolge für das Beenden der Dienste sollte durch systemd festgelegt sein), aber da der User vdr eine aktive X-Session hat, sollte man da sowas nutzen können (es darf währenddessen allerdings kein anderer Nutzer angemeldet sein, damit das ohne Authentifizierung klappt):

    Code
    <command name="Rechner neu starten" confirm="yes" execute="echo /sbin/reboot | /usr/bin/at now -M"/>

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da Polkit bei Ubuntu 18.04 leider zu alt ist, um flexible Regeln in *.rules Dateien zu erlauben, muss man für den Neustart des VDR und des Rechners weiterhin über sudo gehen:

    Code: /etc/sudoers.d/yavdr
    vdr ALL=NOPASSWD: /bin/systemctl --no-block restart vdr.service
    vdr ALL=NOPASSWD: /bin/systemctl --no-block reboot

    Und in der menuorg.xml würde das dann so aussehen:

    Code
    <command name="VDR neu starten" confirm="yes" execute="sudo /bin/systemctl --no-block restart vdr.service"/>
    <command name="Rechner neu starten" confirm="yes" execute="sudo /bin/systemctl --no-block reboot"/>

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Zum Starten von Standalone Desktop-Anwendungen gibt es den Befehl frontend-dbus-send switchto APPLICATION, also z.B. wenn man sich nicht durch das Menü des Desktop-Plugins hangeln will (die Namen müssen entweder der .deskop-Datei für die Anwendung oder einer Systemd-Unit für die Systemd User-Session entsprechen (Beispiel für KODI 17)):

    Code
    frontend-dbus-send switchto kodi
    frontend-dbus-send switchto firefox
    frontend-dbus-send switchto debian-xterm

    Wenn man lieber über irexec geht, kann man die Fernbedienungstasten für die Anwendungen in der /var/lib/vdr/.lircrc definieren. Das Wechseln zwischen zwei Anwendungen geht mit dem Argument switchbetween, also z.B. um zwischen dem VDR und KODI zu wechseln:

    Code
    begin
        prog = irexec
        button = KEY_HOME
        config = frontend-dbus-send switchbetween kodi vdr
    end

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Problem 1 error: no video mode in GRUB habe ich leider immer noch. In der Zwischenzeit habe ich mittlerweile nomodeset als Kerneloption, nvidiafb und vesafb in der initrd sowie weitere Konfigurationsoptionen in /etc/default/grub versucht. Er mag mich nicht... :-/


    Problem 2 (ein Zombieprozess, namentlich [uname]) besteht auch immer noch. Hier habe ich so überhaupt keinen Schimmer, was es sein könnte.


    Neu hinzugekommen Erledigt sind Mikroruckler im Livebild sowie in den Aufnahmen. Auffälligkeiten im LOG gibt es nicht, der TV läuft auf 50Hz, den Zweitmonitor habe ich manuell auf 60Hz festgesetzt. Momentan habe ich softhddevice-openglosd im Einsatz, da alle anderen Varianten Probleme bei der Darstellung des OSD gezeigt haben.


    Die Lösung war bei softhddevice Skalierung auf anamorph und Deinterlace auf TemporalSpatial sowie{ForceCompositionPipeline=Off, ForceFullCompositionPipeline=Off} in /etc/X11/xorg.conf


    Erledigt hat sich das permanente zappen durch die Kanäle. Im Gehäuse ist zusätzlich zum AtricUSB noch ein iMON Display samt IR-Empfänger verbaut und entweder beißt sich das in der jetzigen Konfiguration oder aber der IR-Empfänger ist defekt, jedenfalls kommt von ihm ständig ein CHAN+ am VDR an. Momentan habe ich das Teil mittels

    Code
    /etc/modprobe.d/imon.conf:
    
    blacklist rc_imon_pad
    blacklist imon
    blacklist rc_core

    geblacklisted und das Problem ist beseitigt. Schön wäre zwar, wenn ich das Display noch nutzen könnte, hat aber keine Priorität.



    Cheers,

    Ole

    Einmal editiert, zuletzt von OleS ()

  • seahawk1986,


    hatte nun doch vorzeitg die moeglichkeit, weiter zu testen. deine tips aus

    den vorigen posts #12 und #14

    funktionieren wunderbar - besten dank



    OleS


    zu deinen mikrorucklern: teste doch mal folgendes:


    anstatt

    {ForceCompositionPipeline=Off, ForceFullCompositionPipeline=Off}

    diese line:

    { ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0 }


    am ende der xorg.conf:


    Code
    Section "Extensions"
         Option    "Composite" "Disable"
    EndSection


    und im setup von softhddevice:


    Code
    softhddevice.1080i.Deinterlace = 2
    softhddevice.1080i.SkipChromaDeinterlace = 0
    softhddevice.1080i_fake.Deinterlace = 2
    softhddevice.1080i_fake.SkipChromaDeinterlace = 0
    softhddevice.576i.Deinterlace = 3
    softhddevice.576i.SkipChromaDeinterlace = 0
    softhddevice.720p.Deinterlace = 2
    softhddevice.720p.SkipChromaDeinterlace = 0
    softhddevice.60HzMode = 0


    hier sind die mikroruckler und das tearing mit diesen einstellungen komplett weg



    gruss

    beinhart

  • beinhart danke für den Tipp, allerdings hatte ich das Problem für mich bereits in Post #15 erledigt.

    Ich bin gerade am nachvollziehen, warum bei mir der Zombie aus lircd/uname entsteht. Eventuell hängt

    das ja auch mit meinem anderen Problem bzgl. das ständigen zappens, wenn imon/rc_core aktiv ist

    zusammen... Mal sehen.


    Cheers,

    Ole

  • Im Gehäuse ist zusätzlich zum AtricUSB noch ein iMON Display samt IR-Empfänger verbaut und entweder beißt sich das in der jetzigen Konfiguration oder aber der IR-Empfänger ist defekt, jedenfalls kommt von ihm ständig ein CHAN+ am VDR an.

    Du könntest den Eintrag für rc-core Geräte aus der udev-Regel für eventlircd entfernen (also /lib/udev/rules.d/98-eventlircd.rules nach /etc/udev/rules.d/ kopieren und den Abschnitt https://github.com/yavdr/yavdr…v/98-eventlircd.rules#L62 rausnehmen. Dann sollte eventlircd die Tastendrücke ignorieren.


    Falls es die Knöpfe am IMON-Display sind, die Unsinn senden, wäre das diese Regel: https://github.com/yavdr/yavdr…ventlircd-names.rules#L46

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Du könntest den Eintrag für rc-core Geräte aus der udev-Regel für eventlircd entfernen

    Perfekt, kein Zappen mehr und das Display kann angesprochen werden. Danke!

    Der Zombie Prozess ist allerdings immer noch vorhanden...das war's also nicht. :)


    Cheers,

    Ole

  • Und noch ein Thema ;)


    1920x1080@24Hz ist unter Kodi nicht mehr möglich


    Sowohl AVR und TV unterstützen dieses Format, in der CustomEDID des TV ist auch eine entsprechende Zeile vorhanden. Kodi ist in Version 18 aus dem Nightly Repo installiert und unter Settings > Player > Video ist Adjust display refresh rate auf always gestellt.

    Bisher habe ich vermutet, dass es an der jetzigen xorg.conf liegt und diese für den TV folgendermaßen angepasst:

    Das hat allerdings auch nichts gebracht... :-/


    Für Tips bin ich wie immer sehr dankbar.


    Cheers,

    Ole


    Anbei noch die CustomEDID vom TV:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!