[Gelöst] VDR beachtet den Wert TRY_AGAIN aus Shutdown-Skripten nicht

  • Ich habe ein Skript als Shutdown-Hook, das beim Herunterfahren des VDR prüft, ob der DLNA-Server des Rechners gerade offene Verbindungen hat und das Ausschalten in diesem Fall um 10 Minuten verzögert. Damit der VDR herunterfahren darf, dürfen bei drei aufeinanderfolgenden Prüfungen (sprich: Ausschaltversuchen) keine offenen Verbindungen bestanden haben. Schließlich möchte man ja nicht, dass sich der VDR mal eben beim "Umschalten" zwischen gestreamten Videos schlafen legt... doch genau das passiert, wenn man etwa nach einem Video mal kurz einen "Health check" einschiebt, um erst danach das nächste zu starten.


    Eine erste Analyse von syslog zeigt, dass das Skript wunschgemäß dreimal hintereinander eine Verzögerung von jeweils 10 Minuten anfordert. Zum Beispiel hier:

    Der VDR quittiert die Verzögerung um 10 Minuten auch entsprechend:

    Quote

    Sep 27 22:35:02 HTPC vdr-shutdown: /usr/local/lib/vdr/shutdown-hooks/S80.dlna requests to try again in 10 minutes

    Doch der nächste Versuch startet nicht erst nach 10 Minuten, sondern bereits nach 5 Minuten:

    Und nicht einmal 5 Minuten, sondern schon vier Minuten später passiert es dann:

    Das entspricht nicht dem – zumindest intuitiv – erwarteten Verhalten:

    • Wenn der VDR in seinen normalen Shutdown-Timeout läuft, darf er gerne alle 5 Minuten einen Ausschaltversuch unternehmen.
      • Exkurs: Sobald man eine Taste drückt sollte der Shutdown-Timeout aufgrund der Nutzeraktivität wieder von vorne beginnen (bei mir sind das drei Stunden). Tut er aber nicht: man muss schon ein paar Mal die Power-Taste drücken und das Ausschalten gleich danach manuell abbrechen, damit der VDR Ruhe gibt.
      • Wenn man es nicht geschafft hat, das Ausschalten manuell abzubrechen, geht das Drama kurz darauf von vorne los. Im schlimmsten Fall – und das ist mir auch schon ein paarmal passiert – schaltet sich der Rechner selbst mitten in der Wiedergabe einer Aufzeichnug ohne Vorwarnung aus.
    • Wenn ein Shutdown-Hook eine andere Verzögerung anfordert, sollte der VDR diese beachten und nicht schon vor der angeforderten Zeit den nächsten Versuch unternehmen.

    Hat jemand ähnliche Erfahrungen gemacht? Vielleicht kann kls nochmals erläutern, wie das Zusammenspiel der beiden Mechanismen gedacht ist. Der Code in vdr.c ist diesbezüglich etwas komplex, weshalb ich noch nicht so richtig schlau daraus geworden bin.


    Zumindest fand ich es doch sehr irritierend, mitten im Video (sowohl remote beim Streaming als auch direkt beim Schauen auf dem VDR) auf einmal den Rechner ausgeschaltet zu bekommen.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Ist das das ungefilterte Syslog oder nur die Logmeldungen des VDR?


    Bei einem yavdr-System ist das Frontend-Skript engmaschiger bei Shutdown-Versuchen, auch wenn mir nicht klar ist, wie es in den Zustand gekommen sein könnte, dass es den Rechner weiterhin herunterfahren will, wenn der Nutzer Tasten drückt - es sei denn die Tastendrücke kommen nicht über eventlircd bzw. welcher Dienst sonst /run/lirc/lircd stellt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ist das das ungefilterte Syslog oder nur die Logmeldungen des VDR?

    Das sind nur die Meldungen, die zeigen sollen, dass das Zusammenspiel zwischen dem Shutdown-Hook und den anderen internen Shutdown-Mechanismen des VDR nicht so funktioniert, wie man es erwarten würde.


    Als Fernbedienung dient die interne FB einer TT S2-6400 mit dem Plugin remote. Da aber alle Tasten vom VDR verarbeitet werden, ist das wohl eher nebensächlich.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Soweit ich das sehen kann ( http://git.tvdr.de/?p=vdr.git;…04b624802f05;hb=HEAD#l127 ), hat der Rückgabewert des Shutdown-Skripts keine Auswirkung darauf, wann der VDR den Shutdown erneut versucht, d.h. solange die internen Kriterien für den Shutdown erfüllt sind, wird er es gemäß den hartkodierten Wartezeiten einfach erneut versuchen: http://git.tvdr.de/?p=vdr.git;…8b00d14a6d6;hb=HEAD#l1560 ff.


    Die Wartezeiten sind in der vdr.c weiter oben definiert ( http://git.tvdr.de/?p=vdr.git;…fc8b00d14a6d6;hb=HEAD#l79 :(

    Code
    #define SHUTDOWNWAIT         300 // seconds to wait in user prompt before automatic shutdown
    #define SHUTDOWNRETRY        360 // seconds before trying again to shut down


    Die TRY_AGAIN Variable steckt nur im Shutdown-Skript - das sieht z.B. so aus:

    Und das spawnt bei jedem Aufruf eine Shell mit nohup, die für TRY_AGAIN Minuten schläft, bevor sie ein svdrpsend HITK POWER an den VDR ohne Rücksicht darauf schickt, ob der Nutzer den Shutdown durch Aktivität abgebrochen hat. Mit 10 Minuten für TRY_AGAIN und um die 5-6 Minuten zwischen den Shutdown-Versuchen des VDR können da also leicht 2 solcher Prozesse akkumulieren, die einen noch nerven können, wenn man den VDR dann wieder nutzt.


    Soweit ich weiß, gibt es keine eingebaute Möglichkeit den VDR von Außen zu fragen, ob der Nutzer (in)aktiv ist, das dbus2vdr Plugin bietet diese Möglichkeit: https://github.com/flensrocker…r/blob/master/README#L334 - und wenn meine Theorie stimmt, sollte es genügen, wenn man

    Code
    nohup sh -c "( sleep $(( $TRY_AGAIN * 60 )) && $svdrpsend \"HITK Power\" )"

    in

    Code
    nohup sh -c "( sleep $(( $TRY_AGAIN * 60 )) && {
        vdr-dbus-send /Shutdown shutdown.IsUserActive | grep -Fq \"boolean true\" && exit
        $svdrpsend \"HITK Power\"
    } )"

    ändert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi seahawk1986 , vielen Dank für die Analyse. Da dachte ich noch optimistisch, ich hätte mit den Plugins, für die ich unlängst Patches geliefert hatte, jetzt alle offenen Baustellen geschlossen – und schon geht es weiter


    Kein Ahnung, ob sich auf Basis deiner Hinweise eine (schnelle und möglichst einfache) Lösung erarbeiten lässt.


    Gibt es eigentlich eine Anleitung, wie sich für den VDR am besten eine Entwicklungsumgebung einrichten lässt? Also welche IDE zu empfehlen ist (Eclipse, Code::Blocks, VS Code, …), wie man sie am besten installiert bzw. konfiguriert usw.


    Viele Grüße

    Stefan

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Kein Ahnung, ob sich auf Basis deiner Hinweise eine (schnelle und möglichst einfache) Lösung erarbeiten lässt.

    Eigentlich wird TRY_AGAIN in den Shutdown-Hooks nur benötigt, wenn man ein kleineres Intervall für einen weiteren Shutdown-Versuch will als der VDR selbst vorgeben würde oder z.B. Benutzeraktivität im VDR verursacht.


    Wenn du von einem Zähler auf einen Unix Timestamp Vergleich zum letzten Zeitpunkt an dem ein DLNA-Client aktiv war umstellst (und den Standard-Timestamp auf 0 setzt), kannst du auch komplett auf TRY_AGAIN verzichten - also grob so:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, den Gedanken hatte ich auch schon. Trotzdem finde ich es unschön bis irritierend (und funktional eigentlich falsch), dass TRY_AGAIN mehr oder weniger ignoriert wird. Danke jedenfalls für deine Hilfe.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • Ich bin mittlerweile genervt: Gestern wollte sich der VDR mit dem üblichen Countdown von 5 Minuten abschalten, weil ich mehr als drei Stunden lang in einem Terminal-Fenster an den Plugins gearbeitet hatte. Allerdings verhindert ein Shutdown-Hook das Abschalten, solange noch eine interaktive Sitzung geöffnet ist.


    Damit der VDR sauber für die wenige Minuten später geplante Aufnahme aufsetzt, habe ich den Rechner neu gebootet (sudo reboot). Zu meinem Erstaunen hat sich der Rechner nach nicht einmal 5 Minuten abgeschaltet, so, als ob er noch von dem laufenden Countdown wüsste und danach handeln müsste; der wirkliche Grund ist aus dem Syslog nicht ersichtlich.


    Die letzte Überarbeitung des Shutdown-Verfahrens taugt meiner Meinung nicht. Schon gar nicht, wenn man Shutdown-Hooks für die Steuerung einsetzt, ob bzw. wann der VDR herunterfahren darf.

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

    Edited once, last by shofmann ().

  • Dank der Analyse von seahawk1986 habe ich das Shutdown-Verfahren inzwischen besser verstanden und glaube zu wissen, warum sich der VDR so seltsam verhalten hat:


    Ich hatte bislang noch ein Shutdown-Skript im Einsatz, das auf dem Entwurf von Tobias Grimm beruhte. Wenn einer der aufgerufenen Shutdown-Hooks eine Verzögerung des Shutdowns angefordert hatte, wurde per svdrpsend HITK Power zeitgesteuert das Drücken der Power-Taste emuliert, um den nächsten Shutdown-Versuch einzuleiten. Dieser Mechanismus überlagert sich aber mit dem 5-Minuten-Countdown des VDR, sodass am Ende etliche solcher Power-Tastendrücke in der Pipeline sind. Und irgendwann treffen dann auch zwei so kurz hintereinander ein, dass der VDR einen erzwungenen Shutdown ("Power zum Erzwingen") ausführt – auch während einer laufenden Aufnahme oder Wiedergabe.


    Ich habe das Shutdown-Skript nun so geändert, dass es von allen angeforderten Verzögerungen die am weitesten in der Zukunft liegende ermittelt. Am Ende eines jeden Aufrufs prüft das Skript, ob die Wartezeit schon abgelaufen ist, und kehrt ohne weitere Aktion zum VDR zurück, wenn der Shutdown noch nicht erfolgen darf (womit ein neuer 5-Minuten-Countdown startet). Sobald die Wartezeit abgelaufen ist, ruft das Skript hingegen das in der Environment-Variablen SHUTDOWNCMD hinterlegte Shutdown-Kommando (bei mir: rctwake mit entsprechenden Parametern) als Hintergrund-Prozess auf und fährt den VDR dadurch herunter.


    Das "neue" Skript bettet also die "alten" Hooks in die neue Shutdown-Prozedur ein. Ein Hook kann die Verzögerung jederzeit neu setzen und intern entweder eine eigene "Hysterese" implementieren oder sich auf das Zeitmanagement des Shutdown-Skripts verlassen.


    Mit diesen Anpassungen verhält sich der VDR beim Herunterfahren endlich so, wie ich es beabsichtigt hatte! :)


    Wer möchte, findet das "neue" Shutdown-Skript im Anhang. Damit man das Zusammenspiel mit einem Shutdown-Hook nachvollziehen kann (und weil es vielleicht nützlich sein könnte), habe ich den Hook zur Überwachung des DLNA-Streamings ebenfalls beigefügt. Eventuell müssen dort noch die Ermittlung der IP-Adressen (sprich: der Name der inspizierten Netzwerk-Schnittstelle) und die Portnummer angepasst werden.


    Enjoy & viele Grüße

    Stefan

    Files

    Hardware: Antec NSK2480, Asus P8B75-M LX, Intel Core i5-3570T, 4 GB RAM, NVIDIA GT610, TT-Premium S2-6400, 128 GB SSD, 14 TB HDD, Pioneer BDR-207EBK
    Software: Ubuntu 22.04 LTS mit Kernel 6.8 und VDR 2.7.3 (mit offiziellen und eigenen Patches)
    Plugins: devstatus, dvbhddevice, dvd, dvdswitch, epgsearch, extrecmenu, recsearch, femon, live, markad, mlist, osdteletext, remote, screenshot, skinenigmang, skinnopacity, streamdev, systeminfo, undelete, xineliboutput
    Addons: VDR Convert 0.1.0 (angepasst)

  • shofmann

    Changed the title of the thread from “VDR beachtet den Wert TRY_AGAIN aus Shutdown-Skripten nicht” to “[Gelöst] VDR beachtet den Wert TRY_AGAIN aus Shutdown-Skripten nicht”.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!