[yavdr-ansible] Standby

  • Hallo,

    ich habe mich an einer Lösung versucht, um die Nutzung des S3 mit yavdr-ansible zu ermöglichen - dazu wird der VDR beim Initiieren des Standby gestoppt, die DVB-Module entladen und nach dem Resume werden die Module wieder geladen und der VDR erneut gestartet - mich würde interessieren, ob das mit euren DVB-Karten klappt.

    Damit der VDR beim Herunterfahren den Standby statt den Shutdown initiiert, muss man in der /etc/default/vdr die Shutdown-Methode setzen:

    Shell-Script: /etc/default/vdr
    1. SHUTDOWNCMD="/bin/systemctl suspend"

    Wer das Playbook mit dem letzten Stand (die letzte Änderung war vor gut 3 Wochen) ausgeführt muss danach nicht mehr tun als den VDR neu zu starten.


    Wer das Skript lieber von Hand einpflegen will (z.B. weil er das Playbook nicht erneut laufen lassen will), kann das Hook-Skript (ausführbar machen nicht vergessen) selber anlegen:

    Den module-helper (der ursprünglich von Tobi  stammt) gibt es hier nach Python3 portiert:

    Code
    1. sudo wget https://raw.githubusercontent.com/yavdr/yavdr-base/master/usr/bin/module-helper -O /usr/local/bin/module-helper
    2. sudo chmod +x /usr/local/bin/module-helper

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,

    habe es getestet, funktioniert hier wohl ohne Probleme mit den devices.

    Vielen Dank

  • Hallo seahawk1986,


    ich habe den Standby auch getestet. Leider klappt das Aufwachen nicht richtig.

    Nach dem Aufwachen habe ich erstmal kein Bild. Nach erneutem Neustart des VDR über das OSD, kommt das Bild zwar wieder, allerdings ohne Ton.


    Mein Sytsem:

    Intel NUC6CAYH, angebunden an einen Digibit R1 über satip-axe. Das Playbook habe ich vor 3 Tagen installiert.


    Hast Du eine Idee was da schief läuft?

    Liegt da evtl. an einer zweiten Problematik?

    Wenn der NUC ohne eingeschalteten TV hochfährt und der TV später dazukommt, habe ich auch kein Bild.

    Da habe ich irgendwo mal was dazu gelesen, finde es aber nicht mehr.

    Könnte das damit zusammen liegen?


    Gruß,

    Daniel


    P.s. Freue mich sehr das die automatsiche intel-xorg Erkennung nun funktioniert!

  • Hast Du eine Idee was da schief läuft?

    Was steht denn im Log?


    Wenn der NUC ohne eingeschalteten TV hochfährt und der TV später dazukommt, habe ich auch kein Bild.

    Da habe ich irgendwo mal was dazu gelesen, finde es aber nicht mehr.

    Was dem Playbook noch fehlt ist der Schritt aus Zusammenfassung Intel VAAPI & edid.bin bei dem die EDID-Datei und der gewünschte Mode dem Kernel als Argument übergeben wird. Ich hatte da mal angefangen, aber habe noch keine gute Lösung, wie man die Bildschirme durch das Playbook zuverlässig neu erkennen lassen kann, wenn das System mit vorgegebener EDID gestartet wurde.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Welches log?

    syslog?

    Ja, du kannst dir mit journalctl -b -l alles seit dem letzten Booten rausschreiben lassen (oder in eine Datei umlenken).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich muss etwas ausholen.



    Rechner war komplett aus und wurde gestartet.

    Power off auf Fernbedienung aus vdr-plugin-live ( Receiver und TV bleiben an ). Dann aufwecken mittels wakeonlan.

    VDR startet, OSD ist auch da, aber kein Bild. Beim Umschalten kommt "Kanal nicht verfügbar".Nach ca. einer halben Minute kommt plötzlich doch ein Bild inkl. Ton.

    Ab da ist alles in Ordnung.


    Jetzt wieder Power off, dieses mal per Fernbedienung aus ( Harmony ).

    Receiver und TV gehen auch aus.

    Danach einschalten aller Komponenten per Harmony.

    Das yaVDR Symbol wird angezeigt und darunter steht die Aufforderung eine Taste auf der Fernbedienung zu drücken ( Frontend detached. Press any key on your remote to continue ).

    Danach gleiches Verhalten wie oben, nur das nach ca. eine halben Minute zwar das Bild aber nicht der Ton zurück kommen.


    Syslog im Anhang

  • Zur syslog.txt: Für mich sieht das so aus, als ob der VDR nur über SAT>IP Empfang hat und nach dem Aufwachen der Sat>IP Server mit Verzögerung gefunden wird. Wenn du das Netzwerk statisch konfigurierst statt das über DHCP zu machen, sollte die Verbindung nach dem Aufwachen schneller wieder stehen.


    Die syslog1.txt scheint erst gegen Ende des Aufwachens aus dem Standby einzusetzen,

    Hast du schon wie in der Anleitung von fnu beschrieben den Mode und die EDID als Kernel-Bootparameter eingerichtet?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Der VDR hat nur SAT>IP Empfang, das ist richtig. Der SAT>IP Server als auch der VDR erhalten von der Fritzbox immer die gleiche IP.

    Wenn nötig, kann ich den beiden aber auch eine statische IP geben. Oder reicht es dem VDR eine statische IP zu verpassen?


    Die Anleitung von fnu habe ich gestern versucht umzusetzen. Danach musste ich erstmal den kompletten Rechner neu aufsetzen. Irgendwas ist da schief gelaufen.dmesg|grep drm hat unglaublich viele Warnungen in Bezug auf i915 raus geschrieben. Der VDR hatte auch nicht mehr gestartet.

    Jetzt habe ich ein Image uns werde es heute nochmal versuchen.


    Bei mir gabe es unter /sys/class/drm/ einen Ordner Namens card0-DP-1 hier liegt auch die edid. Gestern war die leer. Heute steht was drin.

    Daher kann ich hier wohl weiter machen.

    Alternativ gibt es unter /etc/X11eine Datei Namens edid.DP-1.bin Könnte das die selbe Datei sein?


    Ich bin mir jetzt nur bei dem Kernelschalter in Grub unsicher.

    GRUB_CMDLINE_LINUX="video=HDMI-A-1:1920x1080@50D drm.edid_firmware=HDMI-A-1:edid/edid.bin"

    Muss das für mich so

    GRUB_CMDLINE_LINUX="video=DP-1:1920x1080@50D drm.edid_firmware=DP-1:edid/edid.bin"

    oder

    GRUB_CMDLINE_LINUX="video=DP1:1920x1080@50D drm.edid_firmware=DP1:edid/edid.bin"

    lauten?

    Weil in meiner /etc/X11/xorg.conf.d/20-intel.conf steht:

    Option "CustomEDID" "DP1:/etc/X11/edid.DP-1.bin"

    Siehe hier:

    Oder muss es in Grub mit - (DP-1) und in der xorg ohne - (DP1) geschrieben werden?


    Was hat eigentlich der Eintrag manual_add_modules i915 radeon in der include-edid-data zu bedeuten. Sowei ich weiß benötigt der NUC den i 965 intel Treiber.


    Ich warte jetzt nochmal ab ob Du zu diesen Sachen was sagen kannst. Ansonsten werde ich die Anleitung von fnu nochmal ab arbeiten.

  • Du kannst sowohl einen statischen als auch einen dynamischen Bereich in deiner FritzBox definieren

    zB

    2-100 statisch ,

    101 -200 dynamisch.

    Geräte die wie ein VDR, private Handys, Computer etc. sollten eine feste Adresse erhalten.

    Es reicht aus, wenn du deinem Rechner eine feste Adresse zuweist. Problematisch wird es nur, wenn vorher ein anderes Gerät die Adresse über DHCP verwendet.


    Gruß

    VDR_1:

    Asus J3455-M, GT 710, SSD 240GB, 8GB DDR3, 1x DvbSky S950 with yavdr-ansible (testing)

    VDR_2:

    AsRock J3455, GT 710, SSD 120GB + SATA 400GB, 8GB DDR3, 1x DvbSky S952 with yavdr-ansible (testing)

    VDR_3_Testing:

    AtomiPi with Intel Atom x5-Z8350, 2GB DDR3, 16GB eMMC, 1x Sundtekt DVB-S with yavdr-ansible (testing)


  • Wenn nötig, kann ich den beiden aber auch eine statische IP geben. Oder reicht es dem VDR eine statische IP zu verpassen?

    Es sollte genügen, wenn der VDR eine statische Netzwerkkonfiguration/IP bekommt (damit er unabhängig vom DHCP-Server der Fritzbox das Netzwerkinterface konfigurieren kann, wenn man will kann man sich auch noch zusätzlich eine IP von der Fritzbox holen). Er braucht nach dem Aufwachen möglichst schnell die richtige Broadcast-Addresse, damit das satip-Plugin den SAT>IP Server finden kann.


    Auf meinem Testrechner sieht das z.B. so aus:

    Bei mir gabe es unter /sys/class/drm/ einen Ordner Namens card0-DP-1 hier liegt auch die edid. Gestern war die leer. Heute steht was drin.

    Daher kann ich hier wohl weiter machen.

    Alternativ gibt es unter /etc/X11eine Datei Namens edid.DP-1.bin Könnte das die selbe Datei sein?

    Der Inhalt sollte identisch sein, die Quelle ist eine andere - die EDID-Datei in /etc/X11 erstellt yavdr-ansible aus dem EDID-Hexstring in der Ausgabe von xrandr --verbose wenn die angeschlossenen Displays geprüft werden. Die Datei in /sys/class/drm/ stellt die EDID bereit, die der Kernel (vom Monitor) ausliest.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Für die Nachwelt:

    Die statische IP konnte ich nur über /etc/netplan/01-netcfg.yaml erfolgreich konfigurieren.

    Anmerkung: Das ging früher aber auch einfacher :cursing:

    Code
    1. network:
    2. version: 2
    3. renderer: networkd
    4. ethernets:
    5. enp3s0:
    6. dhcp4: no
    7. addresses: [192.168.xxx.xx/24]
    8. gateway4: 192.168.xxx.x
    9. nameservers:
    10. addresses: [192.168.xxx.x,8.8.8.8,8.8.4.4]
  • Naja, das ist halt der ganz heiße Sch#+%! von Ubuntu 18.04. ;-)

    Willkommen im #Neuland :-D


    Cheers,

    Ole

  • Zur Anöleitung von fnu:


    Da bin ich etwas verwirrt. Das hatte ich bereits vor der Änderung auf die statische IP erledigt. Danach gab mir dmesg|grep drm ein Ähnliche Ergebnis wie es fnu geschrieben hatte aus.

    Diese Zeile war so ähnlich bei mir zu sehen ( leider habe ich das nicht in eine Datei geschrieben oder kopiert )

    [ 1.850036] [drm] Got external EDID base block and 1 extension from "edid/edid.bin" for connector "HDMI-A-1"

    Bei mir halt mit DP-1 anstatt HDMI-A-1.

    Als och mir die Ausgabe, mit statische IP, nochmal hab anzeigen lassen, kam diese Meldung heraus ( rest in der der anhängigen Datei ).

    Irgendwie kann ich mir nicht Vorstellen das das mit der Ip Änderung zusammen hängt.


    Meine /etc/X11/xorg.conf.d/20-intel.conf sieht so aus:

  • Meine /etc/X11/xorg.conf.d/20-intel.conf sieht so aus:

    Bei mir war es zwingend erforderlich einen Mode aus der EDID in die xorg.conf zu schreiben und den zu nutzen (Zeile 23 und 29). So wie du das geändert hast, kann es gut sein, dass er den Mode nicht statisch setzt, weil er nichts passendes anhand des Namens findet.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke, das könnte es gewesen sein. Dachte eigentlich diese Möglichkeit schon ausprobiert zu haben. Der Standby funktioniert allerdings trotzdem nicht besonders. Also das gleiche Verhalten nach dem wakeup. Als letztes hatte ich sogar nur die Konsole zu Gesicht bekommen.

    Das werde ich aber nochmal checken sobald der Fernseher frei gegeben wird.

  • Also, nach dem Standby dauert es genau 1,05 Minuten bis das Bild kommt. Allerdings kommt der Ton nun zuverlässig mit. Das liegt wohl an dem Work Around von fnu!

    Was kann ich denn noch versuchen?

    Booten aus S5 dauert jedenfalls nicht so lange 😋



    Allerdings kommt immer die Aufforderung: Frontend detached. Press any key on your remote to continue.

    Diese Meldung kommt übrigens auch wenn man während einer Aufnahme versucht den VDR auszuschalten.

    Weiterhin startet der VDR nach dem Aufwachen aus dem Standby immer mit dem ersten Kanal und nicht auf dem letzten Kanal, wie eingestellt.

  • Was steht denn jetzt im Log?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Anbei das log.

    Wo kommen eigentlich die Fehler her:

    Code
    1. Feb 07 22:44:11 vdr vdr[5372]: Selected deinterlacer for resolution 0 is not supported by HW
    2. Feb 07 22:44:11 vdr vdr[5372]: Selected deinterlacer for resolution 1 is not supported by HW
    3. Feb 07 22:44:11 vdr vdr[5372]: Selected deinterlacer for resolution 2 is not supported by HW
    4. Feb 07 22:44:11 vdr vdr[5372]: Selected deinterlacer for resolution 3 is not supported by HW
    5. Feb 07 22:44:11 vdr vdr[5372]: Selected deinterlacer for resolution 4 is not supported by HW