Kodi + VDR: Shutdown Handling

Im Prinzip ja, mit einigen Einschränkungen im Kleingedruckten und mit der Idee, das ganze in einer Systemd-User Session auszuführen: https://github.com/seahawk1986/arch-frontend

Zitat von Copperhead

System startet direkt Kodi
VDR läuft im Hintergrund mit softhddevice detached

softhddevice mit dem Argument -D zu starten ist ja nicht schwer, in der Konfiguration von arch-frontend kann man festlegen, ob mit KODI oder einem unterstützten VDR-Frontend gestartet werden soll: https://github.com/seahawk1986…c/conf.d/frontend.conf#L8

Zitat von Copperhead

Ich kann von Kodi aus den VDR erreichen (attachen)
Ich komme vom VDR zurück zu Kodi.

Das löse ich über eine Taste auf der Fernbedienung, die die Frontends durchwechselt : https://github.com/seahawk1986…/conf.d/frontend.conf#L13
Alternativ geht das natürlich auch über irexec, die commands.conf des VDR, menuorg oder jede andere Möglichkeit, die den Shell-Befehl

frontend-dbus-send /frontend switchFrontend

bzw. das DBus-Äquivalent dazu absetzen kann.

Zitat von Copperhead

Wenn ich in Kodi das System herunterfahre wird das blockiert, wenn ein Timer läuft oder einer kurz bevor steht.
Sollte kein Timer laufen oder bevorstehen, wird die Aufweckzeit gesetzt und das System heruntergefahren.

Nachdem KODI in den aktuellen Versionen keine unterschiedlichen Exit-Codes für normales Beenden, Shutdown, Standby, Neustart usw. mehr liefert, reagiere ich auf die Power-Taste der Fernbedienung als Signal dafür, dass der User den Rechner herunterfahren möchte (das Frontend-Skript kann von einem lirc-kompatiblen Sockel lesen, für HID-Empfänger kann man also z.B. eventlircd oder inputlircd verwenden). Ich löse das aktuell so, dass in dem Fall KODI beendet wird, dann wird das VDR-Frontend kurzzeitig attached und der Shutdown-Befehl an den VDR gesendet. Dann sieht man die Meldung des VDR, wenn er nicht herunterfahren möchte und das Frontend wird wieder detached.

Das mit dem Shutdown-Inhibitor ist ein bisschen zwiespältig - KODI prüft beim Starten einmalig, ob es den Rechner herunterfahren kann - d.h. wenn man den Shutdown-Inhibitor setzt, bevor KODI gestartet wird, ist der Shutdown nicht als Menüpunkt verfügbar. Setzt man ihn nach dem Start, wird der Menüpunkt immer angezeigt, aber der Rechner kann (falls der Shutdown-Inhibitor nicht vom gleichen User gesetzt wurde, unter dem KODI läuft) nicht heruntergefahren werden (wenn es der gleiche User ist, ist der Inhibitor in dem Fall wirkungslos), man bekommt als Benutzer dann auch keine Rückmeldung, warum sich nichts tut.

Das Setzen eines Shutdown-Inhibitors bei Timern sollte prinzipiell nicht schwer sein - dbus2vdr liefert alle nötigen Infos und informiert einen auch per Status-Signal über neu angelegte bzw. von Hand gestartete Timer - ich habe das bislang aber nicht benötigt, da ich davon ausgehe, dass der User KODI nicht mehr sehen möchte, nachdem er die Power-Taste auf der Fernbedienung gedrückt hat.

Da mein VDR mit Arch Linux das letzte Jahr die meiste Zeit nur ohne attachtes softhddevice-Frontend für Aufnahmen lief und Streamdev-Server gespielt hat, habe ich mich nicht allzu intensiv um das Skript gekümmert, sondern nur Fehler behoben, die mir vdr4arch-Nutzer, die ein mehr an yaVDR orientiertes Frontend-Verhalten wollten, gemeldet haben - es kann durchaus sein, dass da noch ein paar Probleme Schlummern, gerade mit KODI als Standard-Frontend habe ich nur wenig getestet.

Falls du noch nicht aufgehört hast zu Lesen und keine gravierenden Bedenken wegen Python, dbus2vdr oder starke Assoziationen mit Rube-Goldberg Maschinen aufgetreten sind, hier noch die PKGBUILDs und die Systemd-Unit dazu (wenn die außerhalb der systemd-User Session laufen soll, sollte man den User, unter dem die ausgeführt werden soll noch festlegen und eine Abhängigkeit zum X-Server/x-login hinzufügen):

pkgname=python-dbus2vdr
pkgver=0.0.2
pkgrel=1
pkgdesc="python bindings for dbus2vdr vdr plugin"
arch=('x86_64')
url="https://github.com/seahawk1986/pydbus2vdr"
license=('GPL')
depends=('python-gobject' 'python-dbus')
provides=('$pkgname')
backup=("etc/conf.d/frontend.conf")
source=(git://github.com/seahawk1986/pydbus2vdr.git)
md5sums=('SKIP')




package() {
  cd $srcdir/pydbus2vdr
  python setup.py install --root="$pkgdir/" --optimize=1
}


# vim:set ts=2 sw=2 et:

pkgname=arch-frontend
pkgver=0.0.1
pkgrel=1
pkgdesc="frontend-manager for vdr and xbmc"
arch=('x86_64')
url="https://github.com/seahawk1986/arch-frontend"
license=('GPL')
depends=('python-gobject' 'dbus-glib' 'python-dbus' 'xdotool' 'xorg-xset' 'feh' 'python-dbus2vdr')
provides=('$pkgname')
backup=("etc/conf.d/frontend.conf")
source=(git://github.com/seahawk1986/arch-frontend.git)
md5sums=('SKIP')




package() {
  cd $srcdir/arch-frontend
  python setup.py install --root="$pkgdir/" --optimize=1
  install -Dm 755 usr/bin/frontend-dbus-send "$pkgdir/usr/bin/frontend-dbus-send"
  install -Dm 755 arch-frontend "$pkgdir/usr/bin/arch-frontend"
  install -Dm 644 etc/conf.d/frontend.conf "$pkgdir/etc/conf.d/frontend.conf"
  install -Dm 644 etc/dbus-1/system.d/de.yavdr.frontend.conf "$pkgdir/etc/dbus-1/system.d/de.yavdr.frontend.conf"
}


# vim:set ts=2 sw=2 et:

[Unit]
Description=Frontend-Script
After=dbus.service
Wants=dbus.service
Requires=dbus.service
AllowIsolate=true


[Service]
Environment=DISPLAY=:0
ExecStart=/usr/bin/arch-frontend
ExecStop=-/usr/bin/frontend-dbus-send /frontend quit
KillMode=control-group
TimeoutSec=10
Restart=on-failure
RestartSec=5


[Install]
WantedBy=default.target

Eine Liste aller verfügbaren DBus-Befehle mit Beschreibung kann ich auch noch heraussuchen, wenn du nicht selbst nach dem Dekorator @dbus.service.method im Quelltext suchen willst.

Zitat

Wenn ich in Kodi das System herunterfahre wird das blockiert, wenn ein Timer läuft oder einer kurz bevor steht.

Sollte kein Timer laufen oder bevorstehen, wird die Aufweckzeit gesetzt und das System heruntergefahren.

Hi, habe das bei mir (vielleicht etwas umständlich) und sicherlich nicht elegant gelöst, es funktioniert aber hervorragend....

Da der VDR das "Energiemanagement" ja eigentlich ganz hervorragend integriert hat, lasse ich ihm auch hier die Oberhand.
In Kodi lasse ich beim exit, shutdown etc. bei VDR mittels SVDRPSEND den Power-button drücken und somit den VDR entscheiden wie es bzgl. abschalten des Rechners jetzt weitergeht.
Der Vorteil ist, dass alle Hooks im VDR dazu abgearbeitet werden und somit zur Verfügung stehen.
Habe dazu ein Skript angelegt:
/usr/bin/xbmc-shutdown.sh

#!/bin/sh
/usr/bin/killall -9 kodi.bin
sleep 1
/usr/bin/svdrpsend hitk power
exit 0

In Kodi muss die "remote.xml" sowie die"/usr/share/kodi/addons/skin.confluence/720p/DialogButtonMenu.xml" dann so angepasst werden, dass dieses Skript bei klick auf Beenden, Shutdown etc ausgeführt wird.

Ändern von:

<power>ShutDown()</power>

in

<power>System.Exec("/usr/bin/xbmc-shutdown.sh")</power>

oder:

sudo sed -i s/'ShutDown()'/'System.Exec("\/usr\/bin\/xbmc-shutdown.sh")'/g /usr/share/kodi/system/keymaps/remote.xml

...sowie
Ändern von:

<onclick>Powerdown()</onclick>

in

<onclick>System.Exec("/usr/bin/xbmc-shutdown.sh")</onclick>

oder:

sudo sed -i s/'onclick>Powerdown()'/'onclick>System.Exec("\/usr\/bin\/xbmc-shutdown.sh")'/g /usr/share/kodi/addons/skin.confluence/720p/DialogButtonMenu.xml

Ändern von:

<onclick>AlarmClock(shutdowntimer,Shutdown())</onclick>

in

<onclick>AlarmClock(shutdowntimer,System.Exec("/usr/bin/xbmc-shutdown.sh"))</onclick>

oder:

sudo sed -i s/'shutdowntimer,Shutdown()'/'shutdowntimer,System.Exec("\/usr\/bin\/xbmc-shutdown.sh")'/g /usr/share/kodi/addons/skin.confluence/720p/DialogButtonMenu.xml

Nachteil: Diese Veränderungen gehen bei jedem Update von Kodi wieder verloren und müssen erneut vorgenommen werden. Beim jetzt anstehenden Wechsel vom Skin Confluence zu Estuary ist die DialogButtonMenu.xml auch in einen neuen Ordner gewandert. Also alles in allem eine ziemliche Krücke, aber funktional

Suspend nutze ich nicht, mit ner SSD bringt das beim Aufwachen eh nur wenig Vorteile aber viele Probleme.....

Gruß
Gero

schöne Anleitung. Danke hierfür.

Was spricht eigentlich dagegen Kodi "richtig" zu beenden? Sprich ohne das "-9".

Mit -9 wird der Prozess ja abgewürgt. Ich kann mir nicht vorstellen, dass das nötig bzw. auf die Dauer gut ist.

Das Problem ist, dass KODI bei einem normalen SIGTERM gerne mal hängen bleibt - besser funktioniert da sowas:

kodi-send --action=QUIT

das wollte ich eigentlich ursprünglich schreiben nachdem ich festgestellt hatte, dass das ein Distri übergreifender Thread ist und ich euer Upstart Script von yaVDR auseinander genommen hatte, aber ich war mir nicht sicher ob das Script zum Kodi Lieferumfang gehört. Dank dir

Ja, das ist bei den EventClients dabei und sollte normalerweise verfügbar sein (bei Ubuntu landet das in einem eigenen Paket - je nachdem welche Paketquelle man hat, heißt das dann kodi-eventclients-kodi-send oder kodi-eventclients-xbmc-send, unter Arch Linux steck es im Paket kodi-eventclients, wie es andere Distributionen machen, habe ich jetzt nicht nachgesehen - da es mit der Standard-Bibliothek von Python läuft, sollte das kein Problem sein das zu nutzen oder es in einer anderen Sprache zu implementieren, wenn man aus "Gründen" kein Python nutzen will): https://github.com/xbmc/xbmc/b…/Kodi%20Send/kodi-send.py

Leider funktioniert das alles nicht wie erhofft, wenn ich "kodi-send --action=QUIT" nutze. Entweder bleibt Kodi beim Beenden hängen oder Kodi startet beim nächsten Start im Fenstermodus (obwohl in den Einstellungen noch Vollbild ausgewählt ist).

Wenn ich den Befehl allerdings aus einer "separaten" Shell losschicke passiert nichts dergleichen.

Hat jemand eine Idee?

Wie genau führst du das aus?

nach dem Beispiel von jlp

Nur "/usr/bin/killall -9 kodi.bin" mit "kodi-send --action=QUIT" ersetzt. Habe auch mal stattdessen "stop kodi" versucht, aber passiert das Gleiche.

Im Moment gehe ich hauptsächlich über das Skin-Menü (Heruntefahren).

EDIT:

Ok, habe es jetzt ganz anders gemacht. Übers Skin-Menü war eh unnötige Arbeit. Habe jetzt das LIRC-Mapping für die Power-Taste aus VDR und Kodi rausgenommen und die Taste in irexec gemapped. Funktioniert jetzt bisher wie gewünscht. Mal sehen wie sich das in den kommenden Tagen im produktiven Einsatz entwickelt

begin
    prog = irexec
    button = KEY_POWER2
    config = if [ "$(/usr/bin/pgrep kodi.bin)" ]; then stop kodi; fi; /usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Remote de.tvdr.vdr.remote.HitKey string:'Power'
end

Bitte beachten, dass ich yaVDR nutze, evtl müsst ihr das etwas umbiegen, wenn ihr was Anderes verwendet.

Ich plane ähnliches und will den Thread deshalb mal wiederbeleben.

Weiß jemand was daraus geworden ist? https://github.com/xbmc/xbmc/pull/4342
Funktioniert diese Lösung und gibt es ein VDR-Addon für Kodi welches diese Schnittstelle unterstützt?

Andernfalls würde ich, bevor ich hier die großen Geschütze auffahre, einen kleinen Patch für Kodi basteln welcher den eingebauten Shutdown-Mechanismus komplett so übersteuert, dass ein Shellscript angesprochen werden kann. Dort könnte dann ein einfaches "svdrpsend HITK POWER" stehen.

Wie schaut es eigentlich hier mit dem Lösung für systemd (Archlinux) aus? Würde gern zwischen VDR (softhddevice und auch rpihddevice) und Kodi umschalten können.

Genau so ist es gedacht.
Ich habe ein entsprechendes System jetzt seit mehreren Monaten im Einsatz. Es wird direkt auf die Kodi-Oberfläche gebootet und der VDR ist als Backend im Hintergrund. Über VNSI werden dann alle nötigen Infos vom VDR nach Kodi übermittelt. Das funktioniert erfreulich stabil bei mir.
Einziger Nachteil: Schneiden geht nicht mehr direkt am HTPC. Ich hole mir dafür bei Bedarf das "Standard VDR-GUI" über xineliboutput an den Desktop-Rechner und schneide dort.

Edit:
Da meine letzte Frage in dem Thread unbeantwortet geblieben ist, schreibe ich mal selber eine Antwort darauf:
Ja, Kodi verweigert ein Herunterfahren wenn der VDR als Backend auf dem gleichen System läuft. Zumindest im Zusammenhang mit VNSI gibt es auch eine sehr gut funktionierende Lösung damit Kodi direkt eine Aufwachzeit setzt. Um auch ein automatisches Runterfahren zu realisieren konfiguriert man in Kodi direkt einfach eine Inaktivitätszeit ab der runtergefahren werden soll. Wenn der VDR aufgenommen hat fährt das System dann runter.
Man merkt dann garnichtmehr das VDR im Hintergrund läuft. Live-TV und Aufnahmen sind sauber in Kodi integriert.

Hallo,
Vielen Dank, jetzt muss ich nur herausfinden wie man das in griff bekommt.
Das heißt VDR ohne softhddevice/rpihddevice aber mit vinsi plugin starten, da wird dann auch Xorg nicht mehr benötigt (wird wahrscheinlich für Archlinux neue vdr.services benötigt wo Xorg Abhängigkeit nicht mehr vorhanden sind). Kodi starten und LiveTV konfigurieren (mit vinsi verbinden)?

So ähnlich. Nur das bei vdr4arch mit meinen letzten Änderungen bereits ein vdr.service reingekommen ist, welches keine Abhängigkeit zu X.org mehr hat. Der alte Weg zum Starten mit X war zu fehleranfällig. Für Start mit X gibt es jetzt ein eigenes Paket "vdr-xorg".
Im Kodi brauchst du dann auch noch das PVR-VNSI Addon. Ist aber alles bei vdr4arch zu finden.
Ich gehe mal davon aus, dass dich Wakeup dann eh nicht interessiert? Am Raspberry wird das eher schwer machbar sein.

Hallo,

der thread ist zwar schon ein paar Monate alt, aber bevor ich einen neuen aufmache ... außerdem ist hier genau das Problem angesprochen, das ich habe:

Zitat von M-Reimer

Edit:
Da meine letzte Frage in dem Thread unbeantwortet geblieben ist, schreibe ich mal selber eine Antwort darauf:
Ja, Kodi verweigert ein Herunterfahren wenn der VDR als Backend auf dem gleichen System läuft. Zumindest im Zusammenhang mit VNSI gibt es auch eine sehr gut funktionierende Lösung damit Kodi direkt eine Aufwachzeit setzt. Um auch ein automatisches Runterfahren zu realisieren konfiguriert man in Kodi direkt einfach eine Inaktivitätszeit ab der runtergefahren werden soll. Wenn der VDR aufgenommen hat fährt das System dann runter.

Das Problem, dass der VDR nach einer Aufnahme nicht herunterfährt wenn ein laufender client über VNSI existiert besteht ja auch, wenn der Client ein separates Gerät ist, z.B. ein Raspi. Es gibt mehrere threads in unterschiedlichen Foren dazu und meistens liest man als Antwort "Das ist korrekt und so gewollt, weil der VDR ja nichts vom Zustand der clients wissen kann.". Zufriedenstellend ist es trotzdem nicht, weil der VDR halt eben nach der Aufnahme durchläuft.

M-Reimer: Was genau meinst du mit der Konfig, dass Kodi nach der Aufnahme "inaktiv" wird, so dass der VDR herunterfahren kann? Wie/Wo stellt man so etwas ein?

Ansonsten bin ich eigentlich der Meinung, dass VNSI hier fast etwas schlauer sein müsste, also dass der Client im richtigen Moment mal "loslässt" oder auch der Server bestimmte Anfragen ignoriert. Auf welcher Seite da etwas passieren müsste, weiß ich spontan auch nicht dafür kenne ich vnsi noch zu wenig.

Grüße,

sebbl

Zitat von sebbl

Auf welcher Seite da etwas passieren müsste, weiß ich spontan auch nicht dafür kenne ich vnsi noch zu wenig.

Im vnsiserver, der setzt regelmäßig den User-Inaktivitätstimeout des VDR zurück, wenn noch Clients verbunden sind: https://github.com/FernetMenta…09093cf97a0/status.c#L183

Zitat von M-Reimer

Am Raspberry wird das eher schwer machbar sein.

Man kann eigentlich jeden IR-Einschalter nutzen (z.B. die IRMP-Empfänger, einen Atric IRWakeupUSB oder einen Y.A.R.D. 2 - mit eigenem Zeitgeber ist auch ein zeitgesteuerter Wakeup möglich) - dann ist es kein Problem den Raspberry Pi über die Fernbedienung wieder anzuschalten. Ansonsten bleibt einem mit einem einfachen IR-Empfänger immer noch KODI zu stoppen, wenn es nicht benötigt wird und dann auf ein IR-Signal hin wieder zu starten.

Also: Eingestellt wird die "Inaktivität" bei aktuellem Kodi-Stable hier:

"System Settings" -> "Power Saving" -> "Sleep / Shutdown"

Diese Einstellung kann verwendet werden, wenn Kodi und VDR wie bei mir auf ein und derselben Kiste laufen.

Was ich selber noch nicht gelöst habe, ist, was man tun muss, wenn ein weiterer Client dazukommt. Zum Beispiel ein Raspberry.

Dann wird der "Haupt-Kodi" direkt auf dem VDR nämlich trotzdem nach seiner Inaktivitätszeit runterfahren auch wenn noch der externe Raspberry TV-Programm streamt. Wie aber kann der "Haupt-Kodi" vom externen Client wissen? Denkbar wäre der Einsatz eines Kodi-Addons das einen Shutdown bei stehender IP-Verbindung verhindert. Das setzt aber voraus, dass ein externer Client eine permanente IP-Verbindung zum VDR hält. Keine Ahnung ob das so ists.