Beiträge von seahawk1986

    Vielleicht hat jemand Lust auszuprobieren, ob es dieser Patch statt dem oben geposteten Ansatz von helau tut - cGlobalTimers::LoadTimers() wird ja noch an anderen Stellen im Plugin aufgerufen, daher scheint es mir sinnvoll das an der Stelle zu beheben, die das Problem mit der Locksequenz hat:

    Fertige Pakete mit dem Patch gibt es in https://launchpad.net/~seahawk…ield.series_filter=bionic - das PPA ist bis auf skindesigner identisch zu ppa:yavdr/experimental-main

    Ich bekomme da immer noch Hänger beim Locking (das scheint bevorzugt aufzutreten, wenn epg2vdr installiert ist:

    Wenn ich das richtig verstehe steckt der angemeckerte Lock in cGlobalTimers::SetLocalTimers() - kann man diese member function asynchron in cGlobalTimers::LoadTimers() aufrufen?

    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
    1. <command name="Rechner neu starten" confirm="yes" execute="echo /sbin/reboot | /usr/bin/at now -M"/>

    Das kann ich hier leider nicht nachstellen. Laut dem Wikipedia-Eintrag kann der Kanal dynamisch zwischen 1080i50 und 1080p25 wechseln, ich weiß nicht, ob softhddevice letzteres beherrscht.


    Du könntest mal die *-dbg Pakete für den VDR und softhddevice installieren und gdb anwerfen, eventuell kann man im Backtrace besser nachvollziehen, woran es scheitert.

    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
    1. $ ps -ef | grep -i defun
    2. root 583 391 0 10:12 ? 00:00:00 [lircd_helper] <defunct>

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

    Ich wüsste nicht, was das bringen sollte den nvidia-340 Treiber in das PPA zu kopieren (das Paket nvidia-384 gibt es nur aus historischen Gründen im PPA, weil im Januar das Paket in den offiziellen Paketquellen zwischenzeitlich kaputt war und ich das Paket aus https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa kopiert hatte).


    Die Kombination aus alter GPU und softhddevice-vdpau-hevc macht in meinen Augen wenig Sinn, die Rechner aus deiner Signatur sind für DVB-T2 zu schwach und wenn man die HEVC-Unterstützung in softhddevice nicht braucht, lohnt sich der Rückgriff auf ffmpeg 3.3 nicht. Ich würde es mal mit vdr-plugin-softhddevice-openglosd oder vdr-plugin-softhddevice-vpp (der Name bezieht sich nur auf das Git-Repo) probieren. Falls alle Stricke reißen könnte ich auch mal probehalber das alte softhddevice ins PPA bringen.

    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).

    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.

    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.

    Letztlich hatte ich keine Idee, wie ich jetzt den vdr auf 60 oder 50 Hz Bildwiederholfrequenz per Konsole testen kann. Wie geht das? Wo werden diese Einstellungen

    Der X-Server wird bei einer NVidia-Grafikkarte über die /etc/X11/xorg.conf konfiguriert und läuft auf DISPLAY=:0.0 (bzw. auf DISPLAY=:0.1 für einen zweiten angeschlossenen Monitor).

    In der Vorkonfiguration sollte er die höchste verfügbare TV-Auflösung (4k, 1080p, 720p, 576p) mit 50 Hz wählen, wenn der Monitor die laut der Ausgabe von xrandr unterstützt. Wenn man eine andere Auflösung oder 60 Hz Modi bevorzugt, kann man wie in yavdr ansible beschrieben die Variablen für das Ansible-Playbook übersteuern, für die Bildwiederholrate wäre das dann z.B. preferred_refreshrates: [60, 50] wenn man Modi mit 60 Hz bevorzugt.


    Im laufenden Betrieb kannst du den X-Server mit nvidia-settings oder xrandr umkonfigurieren, z.B.:

    Code
    1. export DISPLAY=:0
    2. xrandr -q # Anschlussnamen (z.B. HDMI-0), verfügbare Modi und Refresh-Rates ermitteln
    3. xrandr --output HDMI-0 --mode 1920x1080 -r 50 # Würde den Monitor an HDMI-0 auf 1920x1080@50 schalten

    Bei einer GT220 könnte es sein, dass die durch die Einstellungen ForceCompositionPipeline=On, ForceFullCompositionPipeline=On zur Vermeidung von Screen Tearing ausgebremst wird (https://github.com/yavdr/yavdr…emplates/xorg.conf.j2#L51).

    Du könntest das mal versuchsweise auf Off setzen.

    Ansible ist für mich praktisch, weil man mit wenig Wartezeiten Dinge auszuprobieren kann (ein Git-Commit gefolgt von einem Push und einem Pull auf der Testmaschine ist wesentlich schneller als eines oder mehrere Debian-Pakete neu bauen zu lassen) und nebenbei hat man einen zentralen Ort für die Systemkonfiguration.


    Ob man das über die Installation hinaus nutzen will (z.B. weil man sich eine angepasste Vorkonfiguration für sein System erstellt, damit man bei nachfolgenden Installationen weniger Arbeit hat) oder lieber selbst im System herumkonfiguriert, bleibt jedem selbst überlassen.


    Debian-Pakete gibt es weiterhin mehr als genug und wenn es sich anbietet überführe ich auch Teile des Ansible-Playbooks in ein Debian-Paket, wie ich es z.B. für für die systemseitigen Startskripte der X-Session gemacht habe - das Playbook kümmert sich neben der Installation von Paketen hauptsächlich um die Anpassung der Systemkonfiguration und um die Konfigurationsdateien im Home-Verzeichnis des Nutzers vdr, was in Debian Paketen nicht unbedingt gut aufgehoben ist.


    Es stimmt, dass man sich mit Ansible und Git etwas vertraut machen muss, wenn man Anpassungen vornehmen will, die über das Setzen von Variablen und das aus/einkommentieren von Rollen im Playbook hinaus gehen, aber für mich überwiegen die Vorteile, wenn der Nutzer hat die freie Wahl hat, welches Point-Release und welches Installationsmedium für den Ubuntu Server genutzt werden soll und wenn man reproduzierbar eine selbst angepasste Vorkonfiguration auf einem oder mehreren Systemen ausrollen bzw. diese aktuell halten kann.

    Zu eventlircd: ich habe die zusätzliche Aktiverung von eventlicd.socket in der Rolle autoinstall-atric-usb mal rausgenommen. Mit früheren Ansible-Versionen hat das IIRC ohne Probleme funktioniert (eigentlich sollten die Aktionen von Ansible-Modulen immer idempotent sein).

    - Aufnahmeverzeichnis per NFS lässt den vdr wieder nicht starten... Die Berechtigungen stimmen aber, denn mittlerweile schreibe ich alle Zugriffe per squash_all auf anonuid=666 und anongrpid=666 um

    Nur um das besser nachvollziehen zu können: du hast auf dem Rechner, der die NFS-Freigabe bereitstellt, einen User mit uid=666 und gid=666 und der darf alle Verzeichnisse oberhalb des freigegebenen Aufnahmeverzeichnis (in dem Fall also /volume1/) betretren und hat für das Aufnahmeverzeichnis selbst alle Rechte?

    root@sundalon:~# cat /etc/exports
    /volume1/vdr 10.205.1.151(rw,fsid=0,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=666,anongid=666)

    Laut man 5 exports bringt es nichts die Optionen async und no_wdelay zu kombinieren, da letzteres nur bei sync einen Effekt hat.