[XBMC Addon] Powersave für VDR

Sehr interessant!

Gerald

Ich finde es sehr gut, dass für die 'XBMC-Frontend-User' mal was in der Richtung entwickelt wird. So gibt's endlich mal eine vernünftige Trennung zwischen Back- und Frontend und dazu noch "Best of both worlds".

BJ1

ich grabe diesen Thread mal wieder aus, da ich mich aktuell genau mit dieser Thematik - powersaveing in XBMC+VDR - beschäftige; wurde im XBMC Forum auf diesen Thread "geschubst".

Das Addon funktioniert bei mir bestens, auch noch unter dem aktuellen Frodo XBMC 12.1.

Zwei Fragen / Anregungen hätte ich da noch:
-> Wenn ich mir die Funktionsweise des Addons so ansehe, gehe ich richtig in der Annahme, dass es hiermit nicht möglich ist, ein über die "S" Taste ausgelöstet "PowerOff" des Systems abzubrechen, wenn eine Aufnahme in VDR läuft? Zur Zeit fährt XBMC in dem Fall gnadenlos herunter, auch wenn gerade eine Aufnahme aktiv ist....

-> Bzgl. des Netzwerk Idles: Ich benutze in VDR den streamdev-server und auf diversen Androiden AndroVDR, um Live-TV übers Netz auf eben diesen zu schauen, was bestens funktioniert. Könnte man nun nicht per "einfachem" netstat ermitteln, dass auf den Streamdev-Server Ports (3000 / 2004) zur Zeit Geräte verbunden (CONNECTED) sind und aufgrund dessen den Idle TImer "anhalten?

Zitat von Snoopy_1978

Könnte man nun nicht per "einfachem" netstat ermitteln, dass auf den Streamdev-Server Ports (3000 / 2004) zur Zeit Geräte verbunden (CONNECTED) sind und aufgrund dessen den Idle TImer "anhalten?

Das ist halt unpraktisch, weil man ständig pollen muss...
Meine Addon-Lösung für yaVDR (ich hab mir einiges von Telperiars Addon abgeschaut) kann den Shutdown abfangen, wenn XBMC beendet wird - es bietet sich an den Shutdown nicht direkt von XBMC durchführen zu lassen (stattdessen den Exit-Code auswerten, dann den VDR zu fragen, ob gerade ein Plugin oder eine Aufnahme aktiv ist) und dem VDR das Ausschalten zu überlassen.

Zitat von seahawk1986

Das ist halt unpraktisch, weil man ständig pollen muss...
Meine Addon-Lösung für yaVDR (ich hab mir einiges von Telperiars Addon abgeschaut) kann den Shutdown abfangen, wenn XBMC beendet wird - es bietet sich an den Shutdown nicht direkt von XBMC durchführen zu lassen (stattdessen den Exit-Code auswerten, dann den VDR zu fragen, ob gerade ein Plugin oder eine Aufnahme aktiv ist) und dem VDR das Ausschalten zu überlassen.

Das Addon von Telperiar pollt ja sowieso ständig (zu sehen an den "Mark" Einträgen im xbmc.log), unter anderem, um Timer-Updates mitzubekommen.
Der Vorteil der netstat Lösung wäre halt, dass der PowerOff nicht nur dann nicht durchgeführt wird, wenn VDR "was dagegen hat", sondern ganz allgemein gerade per Netz auf den HTPC zugegriffen wird (z.B. SMB/NFS Kopieren etc...)
Ich habe das vorhin mal "ganz dreckig" und rudimentär direkt im installierten AddOn implementiert, quasi als "Machbarkeitsstudie" und das scheint zu funzen...

Sollte man wirklich nur XBMC und VDR (zum Zugriff übers Netz) benutzen ist deine Addon-Lösung für VDR definitiv eleganter, diese kann das PowerOff vom XBMC auch dann "verhindern", wenn man im XBMC per "S"-Menü ein PowerOff auslöst, obwohl gerade eine Aufnahme läuft. Aktuell fährt XBMC dann nämlich gnadenlos runter (s.a. mein Post im XBMC Forum, über den ich überhaupt erst auf dieses Addon gestoßen bin : http://forum.xbmc.org/showthread.php?tid=161780)

Zitat von Snoopy_1978

Der Vorteil der netstat Lösung wäre halt, dass der PowerOff nicht nur dann nicht durchgeführt wird, wenn VDR "was dagegen hat", sondern ganz allgemein gerade per Netz auf den HTPC zugegriffen wird (z.B. SMB/NFS Kopieren etc...)

Wobei ich da einfach die bei den yaVDR bzw. e-Tobi Paketen bestehenden Shutdown-Hooks mit dem Lifeguard-Addon nutze - die machen da letztendlich auch nichts anderes als per netstat nachzufragen (aber eben nur, wenn der VDR selbst keinen Hinderungsgrund für den Shutdown kennt).

Zitat von seahawk1986

Wobei ich da einfach die bei den yaVDR bzw. e-Tobi Paketen bestehenden Shutdown-Hooks mit dem Lifeguard-Addon nutze - die machen da letztendlich auch nichts anderes als per netstat nachzufragen (aber eben nur, wenn der VDR selbst keinen Hinderungsgrund für den Shutdown kennt).

hmm... hört sich auch interessant an, werde ich mir mal anschauen... das funzt auch dann, wenn ich in XBMC per "S" menü den PowerOff auslöse? Sprich, maximal beendet sich XBMC, der HTPC aber läuft weiter? (Nutze keine Fernbedienung sondern ne kleine HTPC Tastatur )

Genau - maximal sollte XBMC beendet werden, wenn der VDR noch etwas zu tun hat.
Abgesehen davon, dass du frei wählen kannst, was beim Druck auf die Taste "s" passiert (also z.B. auch ein Addon/Skript aufrufen) ist es in yaVDR so gelöst, dass der Shutdown-Code von XBMC abgefragt wird (0 = Normales Beenden, 990 = Shutdown, 250 = Reboot) und man dann in einem Skript dementsprechend Aktionen anstoßen kann: In yaVDR 0.5 ist das als Upstart-Job umgesetzt, der aufgerufen wird, wenn der Upstart-Job für XBMC beendet wird: http://paste.ubuntu.com/5689564/
Man kann das aber auch in einem normalen Shell-Skript oder einem eigenen Programm aus dem heraus XBMC aufgerufen wird auswerten.

hab gerade angefangen, das ganze bei mir umzubauen. Wenn ich das richtig hab, benötigt das yavdr-tools Addon im XBMC das aktuellste dbus2vdr Plugin im VDR, richtig? Habe das aus dem unstable-ppa installiert, was einige VDR Updates nach sich zog (war auf 1.7.41), das Ganze sieht jetzt so aus:

vdr (2.0.0/2.0.0) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
femon (2.0.0) - DVB Signal Information Monitor (OSD)
streamdev-server (0.6.0-git) - VDR Streaming Server
dbus2vdr (8) - control vdr via D-Bus
quickepgsearch (0.0.1) - Quick search for broadcasts
wirbelscan (0.0.7) - DVB and pvrinput channel scan for VDR
live (0.2.0) - Live Interactive VDR Environment
xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin
epgsearch (1.0.1.beta5) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
xvdr (0.9.9) - XVDR Server

Wenn ich VDR jetzt starte, ist als letzter Eintrag im Syslog das hier:

vdr: [19405] dbus2vdr: raise SIGSTOP for Upstart

gefällt mir irgendwie nicht VDR macht danach auch nix mehr. Kenne mich noch nicht wirklich mit Upstart aus, bin ein alter init-hase

Wenn ich in der orders.conf das dbus2vdr Plugin deaktivier, funktioniert VDR ohne Probleme

???

Zitat von Snoopy_1978

vdr: [19405] dbus2vdr: raise SIGSTOP for Upstart

gefällt mir irgendwie nicht VDR macht danach auch nix mehr. Kenne mich noch nicht wirklich mit Upstart aus, bin ein alter init-hase

Das macht nur in der yaVDR-Konstellation Sinn, wenn du den VDR über einen Upstart-Job startet (btw: unstable-vdr ist eine schlechte Idee, testing bringt auch einen VDR 2.0.0 mit und funktioniert zuverlässiger - unstable ist die Spielwiese wo auch mal ein Paket kaputt sein kann).
Die Upstart-Aktvierung kannst du in der /etc/vdr/plugin/plugin.dbus2vdr.conf rausnehmen, Shutdown-Hooks und Shutdown-Wrapper brauchst du aber:

#
# Command line parameters for vdr-plugin-dbus2vdr
#
# For more details see:
#   - /usr/share/doc/vdr-plugin-dbus2vdr/README
#   - `vdr --help -Pdbus2vdr`
--shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
#--network
#--upstart

Der Upstart-Job für XBMC sieht übrigens so aus: http://paste.ubuntu.com/5689814/

Top, das hat geholfen.

Da mein VDR unter einem anderen User als "vdr" läuft (derselbe, der auch per autologin am LXDE incl. Autostart vom XBMC angemeldet wird), mußte ich in der DBUS Config den User ändern, damit VDR auf den Bus zugreifen konnte; nun scheint alles zu klappen, XBMC kommt per DBUS an VDR ran (laut debug out im xbmc.log).

Zur Upstart geschichte:
Ich benutze für den VDR ja "euer" ppa, so dass VDR schon per Upstart gestartet wird:

lrwxrwxrwx 1 root root 21 Apr 5 22:50 vdr -> /lib/init/upstart-job

was fehlt dann noch?

Zitat von Snoopy_1978

Ich benutze für den VDR ja "euer" ppa, so dass VDR schon per Upstart gestartet wird:

Bis du mit testing oder unstable unterwegs?
Der vdr-upstart Job kommt in stable und testing noch nicht aus dem VDR-Paket, sondern aus yavdr-base: https://github.com/yavdr/yavdr…ing-0.5/etc/init/vdr.conf

Wenn du im dbus2vdr --upstart gesetzt hast, muss du im upstart job expect stop haben, wenn du es nicht gesetzt hast, darfst du kein "expect-stop" drin haben.

Angenommen, du hast --upstart gesetzt:
echo "expect stop" > /etc/init/vdr.override

Das unser Paket in Ubuntu ein Upstart-Job hat, welcher funktioniert ist aber nur ein paar Tage alt

ok, der eintrag im vdr.override funktioniert, die Meldung

dbus2vdr: raise SIGSTOP for Upstart

taucht zwar immer noch auf, aber daraufhin startet vdr zumindest komplett ... muß mich mal mehr mit DBUS und Upstart beschäftigen, scheint mir...

werde mir in den kommenden tagen auf jeden fall noch eure "komplette" yaVDR distri anschauen; hab leider nur einen einzigen HTPC mit DVB-Karten zum rumprobieren und der wird produktiv im WoZi benutzt... WAF läßt grüßen
Der läuft zur Zeit auf Ubuntu 12.04.2 Minimal/LXDE, VDR aus Euren Repos und XBMC 12.1 aus den offiziellen XBMC Repos ... ach und als Spielerei ist boblight noch dabei *g*

axo, vergessen: bin gerade bei euch auf "unstable" und hab dafür schon was auf die finger bekommen

Wenn es interessiert:
Dieses --upstart und "expect stop" ist nur ein Mittel um besser zu tracken, wann der VDR fertig ist. "expect stop" sagt upstart, das der Prozess ein "kill SIGSTOP" sendet wenn er soweit fertig ist. dbus2vdr ist das letzte Plugin im VDR und führt dann dieses SIGSTOP aus - damit ist zu 99% sicher das der VDR soweit durch ist mit seiner Initialisierung. Vorher gab es Fälle das Verbindungen auf SVDRP fehlgeschlagen sind, da es noch nicht fertig ist. Nun machen wir solche Befehle zum einen über dbus2vdr und zum anderen erst wenn der VDR wirklich fertig ist. Die Meldung im Log ist ja korrekt - und ein guter Indikator ob es ausgeführt wird.

In Ubuntu sollte dbus2vdr dies aber nicht als default setzen (tut es nicht soll das heissen) - und eine Abhängigkeit zwischen dbus2vdr und vdr möchte man auch nicht, also muss es dort manuell angepasst werden, wenn man es möchte.

Zumindest ein erstes Feedback das unser upstart Job in unstable auf "plain ubuntu" funktioniert Gut zu wissen.

axo, verstehe... also hat "--upstart" ansonsten keine weiteren funktionaliäten...

falls es interessant für euch ist, hier ist die komplette cmdline, die von eurem Upstart unter Ubuntu mit den von mir benutzten Plugins gebaut wird:

/usr/bin/vdr -v /home/media/rec -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown.wrapper -E /var/cache/vdr/epg.data -u media -g /tmp --port 2001 --resdir=/usr/share/vdr --cachedir=/var/cache/vdr --dirnames=,,1 -w 60 -P conflictcheckonly -P femon -P streamdev-server -P dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper --upstart -P quickepgsearch -P wirbelscan -P live --port=8008 --ip=0.0.0.0 --log=INFO --epgimages=/var/cache/vdr/epgimages -P xineliboutput --local=none --primary --remote=0.0.0.0:37890 -P epgsearch -P epgsearchonly -P xvdr

Zitat von Snoopy_1978

--port 2001

Wirklich? Das wäre aber nicht im Sinne des Erfinders

I know Das ist noch ein Relikt ... mein HTPC ist historisch gewachsen, hab vor ca. 10 Jahren mal mit nem reinen VDR angefangen und bin seit ca. 2-3 Jahren bei der Kombi VDR+XBMC gelandet (anfänglich eig. nur, weil ich das Design vom XBMC ganz schick fand ), hab also quasi die ganze Entwicklung angefangen von XBMC mit Hilfe von streamdev-server über VNSI bis XVDR mitgemacht *g*