VDR beachtet den Wert TRY_AGAIN aus Shutdown-Skripten nicht

shofmann · Oct 1st 2024

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:

Quote

Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna 1727557140 84298 47 Nachrichten 0
Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna -f $CHECKS [/tmp/S80.dlna.checks]
Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna Previous attempts: 3
Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna Remaining attempts: 2
Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna Host = 192.168.178.25, Port = 8200, Streams = 0, Attempts = 2
Sep 27 23:34:02 HTPC shutdown-hook: S80.dlna $ATTEMPTS [2] -gt 0

Display More

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:

Quote

Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna 1727557140 83936 47 Nachrichten 0
Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna -f $CHECKS [/tmp/S80.dlna.checks]
Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna Previous attempts: 2
Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna Remaining attempts: 1
Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna Host = 192.168.178.25, Port = 8200, Streams = 0, Attempts = 1
Sep 27 23:40:04 HTPC shutdown-hook: S80.dlna $ATTEMPTS [1] -gt 0
Sep 27 23:40:04 HTPC vdr-shutdown: /usr/local/lib/vdr/shutdown-hooks/S80.dlna requests to try again in 10 minutes

Display More

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

Quote

Sep 27 23:44:06 HTPC vdr-shutdown: executing /usr/local/lib/vdr/shutdown-hooks/S80.dlna as shell script

Sep 27 23:44:06 HTPC shutdown-hook: S80.dlna 1727557140 83694 47 Nachrichten 1

Sep 27 23:44:06 HTPC shutdown-hook: S80.dlna -f $CHECKS [/tmp/S80.dlna.checks]

Sep 27 23:44:06 HTPC shutdown-hook: S80.dlna Previous attempts: 1

Sep 27 23:44:06 HTPC shutdown-hook: S80.dlna Remaining attempts: 0

Sep 27 23:44:06 HTPC shutdown-hook: S80.dlna Host = 192.168.178.25, Port = 8200, Streams = 0, Attempts = 0

…
Sep 27 23:44:07 HTPC vdr-shutdown: executing /usr/local/lib/vdr/shutdown-hooks/S90.rtcwake as shell script

Display More

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.

seahawk1986 · Oct 2nd 2024

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.

shofmann · Oct 2nd 2024

Quote from seahawk1986

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.

kls · Oct 2nd 2024

Der Shutdown-Mechanismus wurde in Version 1.5.1 von Urig ziemlich umgebaut. Vielleicht kann er dazu was sagen?

seahawk1986 · Oct 2nd 2024

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:

Bash

#!/bin/sh
#
# VDR Shutdown Script  - Tobias Grimm <tg@e-tobi.net>
# -------------------
#
# see README.Debian
#

. /usr/lib/vdr/config-loader.sh

SHUTDOWN_HOOKS_DIR=/usr/share/vdr/shutdown-hooks/

log="logger -t vdr-shutdown"
svdrpsend="/usr/bin/svdrpsend"

osdmsg()
{
    # OSD message must be deferred, to let VDR display it AFTER the
    # shutdown script has been executed
    sleep 2
    $svdrpsend MESG "$1"
}

shutdownhooks=`find $SHUTDOWN_HOOKS_DIR -maxdepth 1 -xtype f | sort`

for shutdownhook in $shutdownhooks; do
    TRY_AGAIN=0

    if [ -x $shutdownhook ]; then
        $log "executing $shutdownhook"
        result_data=`$shutdownhook "$@"`
    else
        $log "executing $shutdownhook as shell script"
        result_data=`/bin/sh $shutdownhook "$@"`
    fi
    result=$?
    eval $result_data
    if [ $result -ne 0 ] ; then
        $log "Shutdown aborted by $shutdownhook with exitcode $result"
        osdmsg "Shutdown abgebrochen / Shutdown aborted!" &
        [ -z "$ABORT_MESSAGE" ] || osdmsg "$ABORT_MESSAGE" &
        exit $result
    fi

    if [ $TRY_AGAIN -gt 0 ]
    then
        $log "$shutdownhook requests to try again in $TRY_AGAIN minutes"
        nohup sh -c "( sleep $(( $TRY_AGAIN * 60 )) && $svdrpsend \"HITK Power\" )" >/dev/null 2>&1 &
        osdmsg "Shutdown aborted. Retry in $TRY_AGAIN minutes." &
        exit 0
    fi
done

eval $SHUTDOWNCMD &

Display More

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.

shofmann · Oct 2nd 2024

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

seahawk1986 · Oct 2nd 2024

Quote from shofmann

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:

Code: /usr/local/lib/vdr/shutdown-hooks/S80.dlna

#/bin/sh

WORKDIR=/run/vdr
mkdir -p "$WORKDIR"

timeout=$(( 30 * 60 )) # 30 minutes
now=$(date +%s)

LAST_ACTIVE_FILE="${WORKDIR}/last_dlna_client_ts"
last_active_ts=$(cat "$LAST_ACTIVE_FILE" 2>/dev/null || echo 0)

function is_dlna_client_active {
    # TODO: this function checks if a client is active and returns true resp. false
}

if is_dlna_client_active 
then
    last_active_ts=$now
    echo $last_active_ts > "$LAST_ACTIVE_FILE" 
elif [ now -le $(( last_active_ts + timeout )) ]
then
    echo "ABORT_MESSAGE=\"DLNA Client might be still active\"" ; exit 1
fi

Display More

shofmann · Oct 3rd 2024

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.

shofmann · Thursday, 1:33 pm

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.

VDR beachtet den Wert TRY_AGAIN aus Shutdown-Skripten nicht

Participate now!

Share