[XBMC Addon] Powersave für VDR

  • Ich habe dieser Tage, beim "basteln" verblüfft festgestellt dass das ION-330 Board meines Media-Rechners einwandfrei in den S3 Suspend-Mode ging und auch wieder daraus aufwachte. Da ich VDR sehr gerne mit Suchtimern als Backend, und XBMC als Frontend nutze lag nahe Powersave einzurichten. Allerdings gab es da so einige Hindernisse, die Features von VDR fallen diesbezüglich flach, die von XBMC sind noch nicht wirklich befriedigend. Im XVDR Client gibt es wohl Ansätze, die mit meiner persönlichen Nutzung aber nicht wirklich gut zusammenpassen. Also habe ich mich entschlossen selbst ein XBMC-Addon zu schreiben. Es ist nicht nur mein erstes Addon, es ist auch mein erstes umfassendes Python-Projekt.


    Das Addon findet sich im Dateianhang, frei zum Download, und natürlich darf sich nach belieben an Code und Ideen bedient werden. Dafür ist es ja Open Source ;D


    Es läuft nicht völlig "Out of the Box", natürlich muss aufwachen nach Alarmzeit bei euch bereits Funktionieren, und über ein Script ansprechbar sein. Infos zu Funktion und Einrichtung finden sich im "Änderungen"-Bereich des Addons. Dafür läuft es unabhängig vom PVR-Client, es ist also egal ob ihr XVDR oder noch VNSI einsetzt, und in welcher Version.


    Die Kommunikation zu VDR erfolgt über SVDRP. Es harmoniert mit anderen Programmen wie vdradmin-am, denn die Zugriffe auf SVDRP sind immer sehr kurz. Eine Einschränkung ist, das ich keinen Weg gefunden habe das VDR-Backend auf externes Streaming zu prüfen. Jegliches abspielen von Medien an XBMC wird natürlich erkannt, streamt man sein TV-Programm stattdessen an den Rechner, ist das nicht von Leerlauf zu unterscheiden. Vielleicht kennt ja von euch jemand einen Weg über SVDRP an die Anzahl der aktiven Clients zu kommen.


    Ich veröffentliche dieses Addon erst mal exklusiv hier, und falls es sich bewährt vielleicht auch im XBMC-Forum. Anregungen und Bug-Meldungen werden natürlich immer gerne genommen. Viel Spaß!

    Dateien

    Hardware: Point of View ION/ATOM330, 2GB, 160GB (Lokal), 2TB über NFS, Hauppauge Nova-T Stick (2040:7070), SoundGraph IMON (15c2:0036 VFD)
    System: Debian Squeeze, Kernel 3.1.2 (self build), Nvidia 285.05.09, lcdproc 0.5.5, lirc 0.9.0
    VDR: vdr 1.7.21 (etobi) + xvdr (git), xineliboutput, markad
    XBMC: opdenkamp PVR branch (git)

  • :tup


    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?

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


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

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)


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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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



    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


    ???

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

    Code
    1. #
    2. # Command line parameters for vdr-plugin-dbus2vdr
    3. #
    4. # For more details see:
    5. # - /usr/share/doc/vdr-plugin-dbus2vdr/README
    6. # - `vdr --help -Pdbus2vdr`
    7. --shutdown-hooks=/usr/share/vdr/shutdown-hooks
    8. --shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
    9. #--network
    10. #--upstart


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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

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


    was fehlt dann noch?

  • 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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

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


    Code
    1. /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
  • --port 2001


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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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