Posts by frosch01

Quote from zillerbaer

Von einem HW Decoder hab ich da nix gefunden. Ich habe ähnliches mit dem Rockpro64 vor.

Gruss zille

Sieht auch sehr vielversprechend aus. PCIeX4 ist echt cool, und dann noch mit einem normalen Slot. Da könne man schon sehr schön basteln. Du wirst wohl aber einen Kühler brauchen, wenn die CPU dauerhaft hoch takten soll.

Quote from Argus

bist Du sicher, das die brigde laufen wird? Der PCIe Slot ist wohl limitiert (bsw. kein mSATA) --> http://espressobin.net/forums/topic/m…lot-full-specs/

was braucht die brigde alles zum laufen?

Wichtig wird wohl auch sein, was alles in deren eigenen Kernel drin ist. Bsw. kann die HW auf einigen Boards auch SATA-Portmultipliering, im Kernel ist das meist aber nicht drin.

Na ja, ich habe die Cine-S2 drin und die braucht nur einen PCIe-X. So viel kommt da nicht rüber. Selbst wenn es ein v1.0 wäre die bandbreite bei 2.5GBit/s , das sind so rund 250MBtye/s. Laut dieser Seite http://wiki.espressobin.net/tiki-index.php?page=Armada+3700 ist es sogar ein PCIe 2.0, somit kann der 500MByte/s. Es ist definitv "nur" ein X1, das reicht aber allemal, wenn er dann funktioniert..

Quote from S:oren

Ja...

Und, hat das geklappt? Läuft das Teil?

Hallo,

hat sich schon mal jemand an dem Board versucht?

ESPRESSObin

Es ist wohl weniger für eine HD-Ausgabe geeignet, als reiner Server sollte es aber prädestiniert sein. Das Board verfügt über ein Netzteil samt Stromversorgungsausgang, besitzt einen SATA-Anschluss und einen mPCIe Steckplatz für z.B. diese DVB-HW:

Octopus-mini-pcie-bridge

Falls nicht, hat jemand Erfahrungen mit ARM-HW und dem LinuxTV Stack im allgemeinen? Ich kenne aktuell nur USB-Lösungen, hat sich schon mal jemand mit PCIe basierten Lösungen beschäftigt, z.B. mit einem iMX6 Board?

Alles zusammen würde mit dem ESSPRESSObin schon auf ein paar hundert Euro kommen, da möchte ich nicht "umsonst" einkaufen. Der Platz und Strombedarf wären aber überwältigend klein. Wenn ich richtig gerechnet habe würde man mit 6W (ohne LNB-Speisung) auskommen. Da braucht es keine Sparmaßnahmen mehr, das kann dann einfach durchlaufen.

Die Antwort von KDE kam prompt. Immerhin ist der Fehler akzeptiert. Mal sehen ob es irgendwann gelöst wird.

Bzgl des Inhibit habe ich nochmal auf dem dbus gestöbert. Wenn man

qdbus --system --literal org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.ListInhibitors

ausführt, bekommt man alle Inhibitoren angezeigt. Darüber sollte man ein kleines Programm erstellen können, das die Inhibitoren auswertet, evtl. auf vdr als "reason" prüft und im Falle eines vdr-Inhibitors dies dann auf den Session-Bus mapt. Da dieses Vorgehen den inhibitor Mechanismus zweckentfremdet, könnte man auch gleich einen eigenen Service schreiben, der mit dem vdr direkt kommuniziert. Damit wäre dann auch gleich ein VDR Desktop Statusmonitor mit drin.

Wie seht ihr das? Wäre das auch mit anderen Desktops verträglich?

Quote from seahawk1986

IMHO verhält sich da KDE nicht optimal - es müsste erst unter org.freedesktop.login1.Manager CanSuspend aufrufen und wenn das nicht 'yes', sondern z.B. 'challenge' zurück liefert einen automatischen Suspend-Versuch abbrechen, da das nicht nicht-interaktiv ablaufen kann und wenn der Suspend interaktiv aufgerufen wird, könnte es den Nutzer fragen, ob er den Suspend erzwingen will und muss auch damit zurecht kommen, wenn die PolicyKit Authentifizierung fehlschlägt bzw. abgebrochen wird.

Bevor ich den Bug-Report bei KDE gepostet habe, wollte ich die Sache nochmal testen. Der Methode CanSuspend ist übrigens nicht vom logind, sondern von org.freedesktop.PowerManagement.Inhibit. Ich habe das getestet mit aktivem inhibitor:

qdbus org.freedesktop.PowerManagement.Inhibit /org/freedesktop/PowerManagement/Inhibit CanSuspend
true

Das klappt also leider nicht.

Wenn ich an der Kommandozeile vom Sessionuser

systemctl suspend

eingebe, wird der suspend wie zuvor geprüft verhindert (zur Sicherheit nochmal ausgeführt). Ich habe den Bug trotzdem gemeldet, vtl. hat sich die Architektur auf dem dbus auch geändert. KDE hat bestimmt Know-How auf dem Gebiet und weiß wie es gemacht werden müsste.

mini73: Ich habe bereits 6 Downloads für den Patch.

Wenn man idle blockiert geht der Rechner einfach in den Suspend. Ich habe das Inhibit-Programm von einem anderen User ausgeführt und dann den Rechner automatisch einschlafen lassen. Hier das angepasste Python Programm, zur Kontrolle:

#!/usr/bin/python3


import dbus
import logging
import time


bus = dbus.SystemBus()




def inhibit(what='idle', who='First Base',
            why="left field", mode="block"):
    try:
        a = bus.get_object('org.freedesktop.login1',
                                '/org/freedesktop/login1')
        interface = 'org.freedesktop.login1.Manager'
        print("Inhibitor opened: what = {}, mode = {}".format(what, mode))
        fd = a.Inhibit(what, who, why, mode, dbus_interface=interface)
        return fd
    except Exception as error:
        logging.exception(error)
        logging.warning("could not set inhibitor lock")


if __name__ == '__main__':
    my_inhibitor_fd = inhibit()
    #input('press any key to exit inhibitor')
    inhibitTime = 120
    print("Suspend inhibitor will be active for {} seconds".format(inhibitTime))
    time.sleep(inhibitTime)

Gute Nacht

Quote from seahawk1986

Probieren kann man es mal... - du könntest auch noch ausprobieren, ob KDE auf what="idle" bei einem Inhibitor im mode="block" reagiert, das sollte die Aktionen bei Inaktivität betreffen.

Danke für den (weiteren) Tipp! Der vdr muss aber gerade den Tatort aufnehmen. Ich teste das dann danach.

Das Ticket bei KDE erstelle ich morgen.

Ok, hier noch das Patch für den Detach-Mode basierend auf dem master brach von Johns. Das Patch für den VPP-Support Branch hatte noch 2 andere Änderungen mit drin. Ich habe mich inzwsichen gitmäßig besser sortiert und meine Änderungen in Branches sortiert. Ich habe diesen Patch darum auch nochmal angehängt.

Quote from seahawk1986

IMHO verhält sich da KDE nicht optimal - es müsste erst unter org.freedesktop.login1.Manager CanSuspend aufrufen und wenn das nicht 'yes', sondern z.B. 'challenge' zurück liefert einen automatischen Suspend-Versuch abbrechen, da das nicht nicht-interaktiv ablaufen kann und wenn der Suspend interaktiv aufgerufen wird, könnte es den Nutzer fragen, ob er den Suspend erzwingen will und muss auch damit zurecht kommen, wenn die PolicyKit Authentifizierung fehlschlägt bzw. abgebrochen wird.

Soll ich dazu einen Bug-Report an die KDEler schreiben? Vlt. ändern die das dann ja. Einen Versuch wäre es wert!

Quote from seahawk1986

Ich denke, das Problem ist, dass KDE nicht zuerst bei Logind nachschaut, ob es Inhibitoren gibt, sondern direkt Suspend aufruft - ich hatte die gleiche Frage wegen dem Verhalten von KODI auch schon mal im Bugtracker gestellt und die Antwort von L. Poettering war, dass das so gedacht ist, wenn eine Anwendung des gleichen User über DBus auf logind zugreift: https://bugs.freedesktop.org/show_bug.cgi?id=66321
Man mste den Inhibitor also unter einem anderen User setzen, damit er den Suspend in dem Fall blockiert.

Das mit der anderen User wäre im VDR Fall ja implizit so. Ich habe das eben versucht mit positivem Ergebnis. Sowohl der manuelle als auch der automatische Shutdown werden blockiert. In beiden Fällen wir ein Dialog geöffnet um nach einem Freigabepasswort zu fragen. Leider hängt der gesamte Prozess danach an dem Dialog. Auch wenn der Inhibitor geschlossen wird, wird der Suspend aber nicht fortgesetzt. Der Rechner würde also nicht automatisiert einschlafen, wenn der vdr einen Inhibitor gesetzt hat und der Timer für den Shutdown abläuft. Im Anhang das Log von dem Ganzen.

Wenn ich das richtig verstehe, dann hat der KDE damit wiederum nur wenig zu tun, sondern agiert nur als Frontend für das Policy Kit. Der logind sagt dem Policy Kit es solle mal eine Autorisierung einfordern. Und das wartet dann eben. Wie seht ihr das?

So, jetzt erst mal die wenig spektakuläre Erweiterung des Softhddevice-Plugins. Das Patch ist jetzt erst mal für den vpp_branch aus dem presintta repo. Ich erstelle für das vdr-developer repo gleich noch einen Patch. Ich hoffe ich bekomme git in den Griff und kann beide Repos tracken.

Folgendes habe ich gemacht:
* In den Settings unter General wurde eine neue Option eingeführt: "VDR shutdown erlaubt wenn detached".
* Die entsprechenden Abfragen im Plugin-Code habe ich eingeführt.

Folgendes habe ich gestestet:
* Der Shutdown-Counter läuft nicht, wenn die Option nicht aktiv ist.
* DerShutdwon-Counter läuft, wenn die Option aktiv ist.
* Die Übersetzung ins Deutsche wird angezeigt.
* Die Einstellung bleibt über Neustart erhalten.

mini73: Ja, das stimmt schon. Ich könnte das jetzt auch tun und würde das vlt. auch ans Laufen bekommen, mit viel Hilfe. Ich würde mich aber nur auf den Code Style etc. konzentrieren können, für den Rest würde mir das Hintergrundwissen fehlen. Das müssten dann Antti und Johns machen. Johns sagt aber zurecht, dass er den VPP-Code zu wenig versteht und somit die Wartung nicht machen kann. und Antti scheint dafür auch keine Kapazitäten zu haben. Am Ende gäbe es dann ein weiteres Repo eines Ahnungslosen. Sinnvoller wäre es, alle an ein Repo zu setzen und an einer gemeinsamen stabilen Version zu arbeiten. Bleibt aber wohl ein Traum. Den Patch erstelle ich trotzdem mal. Sollte nicht zu viel Arbeit sein und auch für einen Ahnungslosen machbar zu sein.

Ich hatte es in der Tat mit sudo versucht. Als User bekomme ich entsprechend eine Rückmeldung.

systemctl suspend
Operation inhibited by "First Base" (PID 14720 "inhibit.py", user ralph), reason is "left field".
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl suspend -i'.

Wenn ich die Option -i angebe, geht das System dann auch brav trotzdem in den suspend. Das wäre ja i.O. Ein Herunterfahren über den Desktop, sowohl über den direkten Klick als auch über das Energiemanagement, wird aber leider, zumindest bei KDE, nicht verhindert. Na ja, einige KDE Entwickler setzen sich wohl gerade dafür ein den Systemd für weitere Aufgaben zu nutzen. Wie in dem Artikel erwähnt wird, setzt KDE aber bereits beim Session-Management auf den logind, was doch eigentlich zukunftsfähig sein sollte. Ich habe mal folgendes Kommando ausgeführt und dann den Desktop einschlafen lassen:

sudo dbus-monitor --system --profile > dbus.log

Das Ergebnis habe ich angehängt. In Zeile 685 wird ein Suspend an den logind angefragt. Kann jemand abschätzen, ob das zu den Ideen von freedesktop.org passt? Ich werde mal noch ein bisschen stöbern, sieht für mich aber völlig korrekt aus. Die Inhibitoren sind doch eigentlich ein logind feature. Im jounal finde ich leider nichts dazu. Der logind ist aktuell ziemlich wenig gesprächig.

Wenn ich den Suspend über die Kommandozeile absetzte, taucht dann auch kein Suspend-Request im dbus auf. Das passt in das Bild.

mini73: Ich werde es auf einen Versuch ankommen lassen. Ich erweitere das softhhdevice entsprechend und poste dann hier den Patch - als kurzfristige Lösung und zur Ergänzung des Detach mode -. Ich bin aktuell aber gezwungen das presintta repository zu verwenden, da das Plugin auf dem vdr repo mit aktueller Intel HW nicht sauber läuft. Ich bekomme da Ton und Bild nicht synchron und die Videoausgabe ist höchst instabil. Darauf hatte meine Frage auch ein bisschen abgezielt. Wie kann ich die Änderung sowohl bei Johns als auch bei Antti Seppälä in das Repo bekommen? Zwischen den beiden werden aktuell nicht gerade viele Patches ausgetauscht.

Danke für das Programm. Dann brauch ich nicht mal loshacken.

Also bei KDE (5.5) ergibt sich folgendes Ergebnis:

Who: First Base (UID 1000/ralph, PID 14241/inhibit.py)
    What: shutdown:sleep
     Why: left field
    Mode: block


     Who: Telepathy (UID 1000/ralph, PID 1355/mission-control)
    What: shutdown:sleep
     Why: Disconnecting IM accounts before suspend/shutdown...
    Mode: delay


     Who: PowerDevil (UID 1000/ralph, PID 1326/kded5)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: KDE handles power events
    Mode: block


     Who: NetworkManager (UID 0/root, PID 775/NetworkManager)
    What: sleep
     Why: NetworkManager muss Netzwerke abschalten
    Mode: delay

Obwohl der Inhibitor aktiv ist, geht das System auf Anfrage über den Desktop schlafen. Wenn ich systemctl suspend eingebe aber auch. Das scheint irgendwie nicht zu klappen. Hast Du eine Idee?

Ich muss für heute Schluss machen. Habe noch Date....

Daran hatte ich noch gar nicht gedacht. Systemd wäre natürlich spitze, vor allem da der auch gleich das Problem mit dem Zugriff auf die Session löst. Und der vdr müsste "nur" während der Aufnahme und weiteren Aktivitäten einen Lock setzen. Im kde habe ich eben gesehen, dass der Shutdown tatsächlich über den Systembus geht. Das gibt dbus-monitor aus, wenn man über den KDE einen Suspend "ausführt":

Quote

mc 1465056675.566315 12194 :1.22 org.freedesktop.PowerManagement /org/freedesktop/PowerManagement org.freedesktop.PowerManagement Suspend

Ich werde mal versuchen, mit Python ein Programm zu schreiben, dass einen Inhibitor setzt. Dann kann man mal ausprobieren wie sich der Desktop darauf hin verhält. Wenn das auch vdr-intern klappt, wäre das ein prima Lösung....

Ok, das macht Sinn. Diesen Usecase kannte ich nicht. Gut, dass es Leute gibt die die Sache im Überblick haben.

Dein Voschlag, ein Power-Kommando (1. Antwort) zu schicken hatte ich bisher verworfen. Wenn ich die Aktivitätsüberwachung des Desktops verwenden würde und diese so einrichte, dass dem vdr ein PowerOff zugeschickt wird wenn der Desktop herunterfahren möchte, der vdr das dann aber nicht macht da z.B. ein Timer aufzeichnet, würde das weitere Verhalten undefiniert sein. Also müsste der vdr auch schon den Desktop wach halten damit der erst gar nicht herunterfahren möchte. Das könnte man über den dbus ganz gut machen, aktuell kenne ich dafür aber kein Plugin. Am Ende würde der vdr den Desktop wach halten, dieser dann zum Herunterfahren wiederum den vdr bitten. Das klingt alles nicht so richtig dolle. Dann hat man noch das Problem, dass der Session-Bus für den vdr-user gar nicht erreichbar ist. Im vdr müsste das Plugin jede Aktivität mitbekommen, um diese an den Desktop weiterzureichen. Kann ein Plugin das überhaupt?

Für meinen Usecase wäre eine reine vdr Lösung ausreichend, für den Detach-Mode einen Parameter einzuführen, der das von mir gewünschte Verhalten erreicht. Es könnte zwar mal passieren, dass der vdr den Rechner runterfährt während man daran etwas macht, aber dann macht man die Kiste halt wieder an. Ich glaube nicht, dass meine Usecase so abwegig ist - Ein Rechner im Office, der anläuft wenn es was zum Aufnehmen gibt und auch mal als 2.TV dienen kann -. Ein eigenes svdrp Kommando macht für mich weniger Sinn. Ich hatte bis eben schon Schwierigkeiten, SUSP und DETA auseinanderzuhalten. Als Titel für die Einstellung könne ich mir z.B. "Detach verhindert einschlafen" vorstellen. Wäre diese Lösung akzeptabel?

Hallo Forum,

sorry für den späten Beitrag, ich glaube ich kann da einige Infos liefern. CMake ist ein makefile Generator. Wer qmake kennt, weiß was es ungefähr tut. Es ist aber nicht auf C/C++ und QT beschränkt und kann viel mehr als qmake. Ich arbeite seit 5 Jahren mit cmake und sehe folgende Vorteile:

1. Man beschreibt das Projekt auf hoher Ebene und nicht auf Build-Target-Ebene => Die "Makefiles" sind viel kompakter, meist weniger als eine Bildschirmseite.
2. Die Abhängigkeiten werden vollständig erfasst.
3. Out of tree builds. Ich kann in einem Tree gleich für mehrere Platformen bauen. Das wird auch durch den CMakeCache erledigt.
4. Der Cache. Man kann den Build konfigurieren und so auch Beta-Code in den Quellen verteilen. Das lässt sich dann beim Build einschalten. Auch für spez. Libraryversionen etc. einsetzbar.
5. Configuration des Builds wie configure. Methoden im Dateien, Bibliotheken etc zu suchen (find_file, find_library, find_package) Packages sind für die gängisten Bibliotheken dabei (/usr/share/cmake-<ver>/Modules)
6. Package-Konzept - man kann es mögen oder auch nicht.
7. Alles in einem einzigen Dateiformat beschrieben
8. Jedes Verzeichnis hat sein eigenes "Makefile"
9. Properties, um auch mal tiefer eingreifen zu können.
10. Funktions-Konzept zum Erstellen von projektspezifischen Funktionen.
11. Ein Konzept um eigene Targets (Dateien und .phony) einzubringen.
11. Die Dokumentation ist ausreichend.
12. Es ist ein deutsches Projekt.
13. Alle Artefakte sind Textdateien. Keine geheimen Dateiformate.
14. Gute Integration in kdevelop - wer es mag-.
15. Ausflüge in externe Tools werden weitestgehend vermieden.

Was ist unschön:

1. Die Syntax ist, wie schon erwähnt, etwas gewöhnungsbedürftig, was aber immer zutrifft, wenn man sich nicht auskennt. Sie ist aber auf jeden Fall wenig intuitiv.
2. Die Doku hilft am Anfang nicht weiter. Man bekommt immer nur das was man schon weiß als Antworten.
3. Man muss die Variablen und Properties kennen um schwierige Aufgaben lösen zu können.
4. Der Start viel mir ziemlich schwer. Ich habe entsprechend viele Dinge falsch angefangen.

Vielleicht hilft das noch dem Einen oder Anderen....

seahawk1986: Zunächst erst mal vielen Dank für Arbeit an yavdr. Leider läuft yavdr mit meiner HW aktuell nicht und mein Usecase hat sich auch ein bisschen verändert hin zu einem Server. Trotzdem tausendfachen Dank für all Deine Arbeiten!

Für den von dir beschrieben Usecase, den Screen für eine andere Anwendung zu nutzen, sollte eigentlich der "SUSP"-Mode zuständig sein. Man den SUSP mode so einstellen (Plugin Einstellungen), dass er das Selbe wie der "DETA" macht. Im SUSP-Mode wird die Video-Ausgabe, die Audio-Ausgabe und ggf. der X-Server terminiert. Video und Audio liegen allerdings gemeinsam auf der Variablen ConfigSuspendClose, das Terminieren des X-Servers liegt auf ConfigSuspendX11. Das ist diese Codezeile:

Suspend(ConfigSuspendClose, ConfigSuspendClose, ConfigSuspendX11);

DETA sollte, wie hier (von Johns) beschrieben, eigentlich den Shutdown nicht verhindern, was IMHO auch Sinn macht. Das wäre dann dieser Code:

Suspend(1, 1, 0);

SUSP kann also identisch zu DETA konfiguriert werden, startet aber dann aber noch einen dummy player, der vehindert, dass der vdr einschläft, wie in deinem Usecase beschrieben.

cControl::Launch(new cSoftHdControl);
cControl::Attach();

Der selbe Code ist aber auch für DETA drin. Ich habe inzwischen die beiden Zeilen auskommentiert. Ich kann keine negativen Auswirkungen erkennen - was auch nicht zu erwarten war -. Mit erscheint es so, als wäre diese Änderung ausersehen mit reingerutscht. Die Frage ist nun: Bekommt man das so auch in die Git-Repos? Ich möchte eigentlich ungern meinen eigenes softhddevice haben, obwohl ich den Eindruck habe, dass dies für viele vdr-user inzwischen der Normalzustand geworden ist.

@wmauter: Das mit dem Wrapper kommt vom ETobi vdr und ist inzwischen in allen Debian basierten Distris mit drin. Ich habe bei meinen Usecase den vdr-PC auch als normalen PC in Verwendung. Der Rechner wird ab und zum Mailen und Surfen eingesetzt. Der Rechner soll aber auch den vdr-Dienst im Netzt bereitstellen. Das klappt so ganz prima. Am TV habe ich dann einen PI, auf anderen PCs Kodi. Kodi auf dem PI klappt bei mir irgendwie nicht.

Hallo Forum,

ich bin bei meinem neuen vdr ein gutes Stück voran gekommen. Der vdr läuft jetzt stabil, ich kann stundenlang HD-Material anschauen ohne dass etwas quietscht oder hängt und das mit einem N3700 SOC ohne NVidia GPU. Ich betreibe die HW unter Ubuntu 16.04 und möchte das Frontend über Detach/Attach öffnen und schließen. Unabhängig davon soll der vdr selbständig hoch und runterfahren. Und dabei habe ich jetzt ein Problem: Der vdr macht keinen Shutdown (Suspend). Ich kann den vdr jederzeit manuell herunterfahren, aber eben nicht automatisch.

Ich hatte hier einen älteren Beitrag gefunden, in dem es um das selbe Thema ging. Damals war die Aussage, dass im Suspend ein Dummy-Player läuft der den vdr am Einschlafen hindert, was für das Detach aber nicht zutreffen sollte. Dies ist der Beitrag.

Leider konnte ich das nicht nachvollziehen und habe mich ans debuggen gemacht. Ich habe vom vdr-Code keine Ahnung, musste mich also ein bisschen quälen. Am Ende bin ich dann im softhddevice Code gelandet und zwar genau da, wo es um den Dummy-Player geht. Hier der Code zur Modeumschaltung aus softhddevice.cpp:

if (!strcasecmp(command, "SUSP")) {
	if (cSoftHdControl::Player) {	// already suspended
	    return "SoftHdDevice already suspended";
	}
	if (SuspendMode != NOT_SUSPENDED) {
	    return "SoftHdDevice already detached";
	}
	cControl::Launch(new cSoftHdControl);
	cControl::Attach();
	Suspend(ConfigSuspendClose, ConfigSuspendClose, ConfigSuspendX11);
	SuspendMode = SUSPEND_NORMAL;
	return "SoftHdDevice is suspended";
    }


........


    if (!strcasecmp(command, "DETA")) {
	if (SuspendMode == SUSPEND_DETACHED) {
	    return "SoftHdDevice already detached";
	}
	if (cSoftHdControl::Player) {	// already suspended
	    return "can't suspend SoftHdDevice already suspended";
	}
	cControl::Launch(new cSoftHdControl);
	cControl::Attach();
	Suspend(1, 1, 0);
	SuspendMode = SUSPEND_DETACHED;
	return "SoftHdDevice is detached";
    }

Wie man hier sieht, wird in beiden Fällen über cControl::Launch(new cSoftHdControl) ein cSoftHdControl als replay control objekt registriert. Das verhindert dann in main() ein Abschalten, da ja ein Player aktiv ist. Das habe ich zumindest so verstanden. Hier der Code aus main:

Interact = Menu ? Menu : cControl::Control(); // might have been closed in the mean time
        if (Interact) {
           LastInteract = Now;

Dadurch, dass LastInteract = Now gesetzt wird, wird verhindert, dass in main der Shutdown-Block betreten wird.

Könnte mit jemand einen Tipp geben, ob ich diesen Teil entfernen kann, ob das so wie es aktuell drin ist ein Feature ist oder ob es doch eher in den Bereich Bug gehört. Vlt. lässt sich das im letzteren Fall dann auch in den Git-Repos beheben....

Ralph