softhddevice und vdr shutdown

  • 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:



    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:


    Code
    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

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

  • Nur ein Schnellschuß aus der Praxis: bei mir (yaVDR) fährt der VDR selbst den PC herunter - dazu wird allerdings ein C-Wrapper (shutdwnwrapper) benützt, der mit suid das als root-Benutzer überhaupt tun darf, weil der vdr-Prozeß selbst als User "vdr" läuft und nicht die Rechte zum Shutdown hätte.
    Aber egal ob attached oder detached, das hat keinen Einfluß bei mir ...
    Ich verwende zur Schonung der Nvidia-Karte auch ein "detach"-Script, das im wesentlichen einfach alle 30 Sekunden den Fernseher anpingt und je nach Antwort und letztem gemerkten Status des softhddevices dieses attached oder detached. Zusätzlich wird nach dem Detach noch ein "svdrpsend HITK power" geschickt.
    Der VDR selbst fährt dann auch gleich runter, wenn nicht eine Aufnahme ansteht und keine aktive Netzwerkverbindung (vlc, mediatomb, ssh) mehr besteht - was wiederum durch das "lifeguard"-addon und dessen Konfiguration kontrolliert wird.

    Einmal editiert, zuletzt von wmautner ()

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

    Der Grund softhddevice im laufenden Betrieb zu detachen ist ja eigentlich, dass man eine andere Anwendung nutzen möchte. Da wäre es kontraproduktiv, wenn der VDR dann plötzlich den Rechner herunterfährt, während du z.B. gerade einen Film über einen VOD-Dienst ansiehst. Letztendlich ist das einfach eine Design-Entscheidung, man könnte natürlich auch argumentieren, dass sich der VDR davon nicht aufhalten lassen soll und dann über einen Shutdown-Hook (wie das lifeguard-Addon) oder eine Shutdown-Inhibitor (für Systemd/Logind) der Shutdown verhindert wird, wenn bestimmte Kriterien zutreffen.


    Vom Aufwand her ist es IMHO einfacher dem Detach, der von einem Shutdown gefolgt werden soll, ein "svdrpsend hitk power" (oder einen vergleichbaren Befehl über dbus2vdr, restfulapi usw.) hinterherzuschicken als Sonderregeln zu konstruieren, wann der Inaktivitätstimeout nicht zuschlagen darf.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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:


    Code
    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:


    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.


    Code
    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. ;(

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

  • Im Gegensatz zum SUSP kann ein DETA aber nicht vom VDR oder anderen Plugins aufgehoben werden (was wichtig ist, wenn das Frontend für eine bestimmte Zeitspanne nicht wieder aktiv werden darf, z.B. weil KODI die X-Ressourcen und die Alsa-Geräte benötigt oder man zwischendrin den X-Server stoppen können möchte). So wie das aktuell umgesetzt ist, genügt ein Fernbedienungsbefehl an den VDR oder eine von einem Plugin (z.B. Kanalumschaltung in Live, das passiert auch, wenn man svdrpsend remo off setzt) ausgelöste Aktivität , um den Suspend aufzuheben - IMHO macht der Suspend in seiner aktuellen Form nur Sinn, wenn man die Ausgabe von softhddevice gerade nicht benötigt, sie aber jederzeit wieder angeschaltet werden darf, für die anderen Anwendungsfälle ist das IMHO zu wackelig, um sich darauf verlassen zu können.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Gen2VDR sendet z.B. auch ein DETA, wenn es das softhddevice kontrolliert abschalten will.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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?

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

  • 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?

    Ich habe da nichts dagegen (auch wenn ich einen automatischen Shutdown für den Suspend-Modus für naheliegender halte, weil den der Nutzer per Fernbedienung ohne externe Skripte abbrechen kann).
    Ich habe auch schon angefangen mit Ubuntu 16.04 zu experimentieren - ich denke man könnte da einige Funktionen nutzen, die Systemd bietet (z.B. Shutdown-Inhibitoren während eine Aufnahme läuft), um das Shutdown-Verhalten sinnvoller zu gestalten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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":


    Zitat


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

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

  • Ich weiß nicht wie KDE das aktuell macht (das letzte Mal als ich vor ca. einem Jahr nachgesehen hatte, konnte nur die gnome-session laut Dokumentation damit umgehen, aber vielleicht kann KDE das mittlerweile auch). systemd-inhibit sollte zum Testen erst mal genügen.


    In Python müsste das in etwa so aussehen, wenn man einen Shutdown-Inhibitor für logind setzt:

    Das sieht dann während das Skript läuft so aus:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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


    Also bei KDE (5.5) ergibt sich folgendes Ergebnis:



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

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

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


    Deine Frage ist quasi die Antwort: Bei freier und offener Software ist es einfach der Normalzustand, dass jeder seine eigene Software hat, die das tut, was er braucht. Jeder kann und darf und sollte Patches schreiben. Und wenn man es richtig gemacht hat, übernimmt der Maintainer dann den Patch, sollte er davon zu wissen kriegen.


    So funktioniert community getriebene Software-Enticklung. Probiere es aus, es bringt Spaß. :)


    Lars

  • 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?

    Führst du systemctl suspend als Nutzer oder mit sudo aus? Das Verhalten ist normalerweise so, dass Shutdown-Inhibitoren von normalen Usern nur normale User daran hindern den Rechner herunterzufahren. Wenn man den Befehl als root ausführt, hat der Block keinen Effekt: https://www.freedesktop.org/wiki/Software/systemd/inhibit/

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Inhibitoren greifen nur in der gleichen Session. Um sie zu übersteuern (auf dem Desktop) reicht der Wechsel auf ein anderes Terminal. Anders sieht es aus wenn ein Prozess über Systemd gestartet wird und dabei keine Session anlegt. Dann sollte ein Inhibitor system-global wirken. Ich nutze das für meinen Power-Button Daemon um Systemd global zu hindern auf den Power-Button zu reagieren.

  • Also wenn ich eine Systemd User-Session für den User vdr mit xlogin starte und darin einen Shutdown-Inhibitor setze:

    Code
    ├─systemd─┬─(sd-pam)
            │         ├─dbus-daemon
            │         ├─on_vdr───{gmain}
            │         └─xterm───bash───systemd-inhibit───vim


    bekomme ich bei einem Shutdown-Versuch über SSH oder auf einem anderen einem TTY als normaler User eine entsprechende Meldung:

    Code
    $ systemctl poweroff
    Operation inhibited by "vdr user session" (PID 1997 "systemd-inhibit", user vdr), reason is "test".
    User vdr is logged in on /dev/tty7.
    Please retry operation after closing inhibitors and logging out other users.
    Alternatively, ignore inhibitors and users with 'systemctl poweroff -i'.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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


    Code
    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:


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

    Dateien

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

  • 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 müsste den Inhibitor also unter einem anderen User setzen, damit er den Suspend in dem Fall blockiert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

    Systeminfos:
    Kubuntu 16.04 mit vdr 2.2.0, Kernel 4.4, presintta softhddevice, vnsi
    Server/Client: Asrock N3700M, 8Gbyte, DDR3L-1600-CL9, CineS2 V6.5 (LP), 2,5'' Seagate ST1750LM000, IT-502
    Client 1: Pi2 + 38KHz IR Empfänger, Raspbian mit Kernel 4.2, VOMP VDR Client, Remote vom Technisat-TV :D
    Client 2..: Kodi

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!