Beiträge von Cybso

  • Neues XBMC für yaVDR 0.4 in testing

    Was macht denn dein XBMC, wenn du ihn über "Verlassen" beendest? Wenn das klappt (also er entweder zum VDR wechselt oder den XBMC neu startet), dann handelt es sich wohl um ein anderes Problem. In dem Fall würde ich als erstes in /var/log/syslog nachschauen, ob der Lifeguard vielleicht interveniert. Bei einem Standardsetup ist der Lifeguard übrigens so eingestellt, dass er nicht runterfährt, wenn noch ein XBMC läuft. Mag dass das Problem sein?

  • [Wunschkonzert] Livebuffer-plugin

    Zitat von Keine_Ahnung

    Doch, die Pausentaste ist in diesem Moment ja nur dafür da um definiert (und bewusst) in den Replymodus zu gehen. Weil spult man im LiveTV Modus passieren da einige verwirrende Dinge (falsche Displayanzeigen, komische EPG Anzeigen, andere (anderst als beim normalen Replay) Fernbedienungsbelegung usw.).


    Ehrlich gesagt fand ich genau dieses Verhalten immer extrem verwirrend und hätte es lieber anders herum. Warum muss ich erst "Pause" machen wenn ich "Zurück spulen" will? Stell dir mal vor dein DVD -Player würde sich so verhalten (ok, nur schlecht vergleichbar). Und die EPG-Anzeige ist nicht "komisch", sondern nach der Uhrzeit orientiert, da würde ich auch nicht dran rumpfuschen wenn man vor oder zurück gespult hat, dann wird es nämlich wirklich verwirrend. Man könnte jedoch die aktuell laufende Sendung oder den Offset zum Livemodus hervorheben. Das wäre dann aber wieder alles andere als ein kleiner Eingriff, sowas sollte lieber direkt von den Core-Developern kommen. Und gerade die andere Fernbedienungsbelegung im Replay-Modus ist doch sehr verwirrend.


    Ich habe noch etwas weiter nachgedacht, aus Perspektive des von mir bevorzugten Modus. So kompliziert wie am Anfang gedacht wäre die Übergabe des Livebuffers an die Aufnahme gar nicht. Man bräuchte eine globale "Managerinstanz", die den Livebuffer für jeden laufenden Stream verwaltet. Eine beginnende Direktaufnahme, bei mir auf der Fernbedienung auf eine hübsche rote "Record-Taste" gelegt (weiß die Aufnahme eigentlich, dass es eine Direktaufnahme ist?!), würde dann vor dem Start der Aufnahme den Livebuffer fragen, ob er für den ausgewählten Channel Daten vorliegen hat und diese dann vor die eigene Aufnahme anfügen. Oder noch besser, um die Synchronität zu wahren, er würde selbst den gleichen Livebuffer wie die laufende Sendung verwenden. [Edit: Synchronität in dem Sinne, dass keine Unterbrechung in der Aufnahme stattfindet, wenn von den Bufferdaten auf den aktuellen Stream gewechselt wird; nicht Synchronität in dem Sinn, dass eine "Pause" im Liveprogramm aufgezeichnet wird.] Dazu müsste die Hoheit über das Füllen des Buffers dem "Manager" überlassen werden, damit nicht die gleichen Daten doppelt in den Buffer geschrieben werden und bei einem Wechsel des Livechannels die Aufnahme trotzdem fortgeführt wird.


    Ich würde mich wirklich gerne dran versuchen, aber ich möchte mich nicht erstmal eine Woche lang nur damit beschäftigen, den Quelltext zu verstehen (Frau, Kind und Arbeit würden es danken^^). Mag jemand, der den entsprechenden Code sowieso schon kennt, nicht eine Art "Patenschaft" für mich übernehmen, so dass ich ihn bei Fragen löchern kann?

  • [Wunschkonzert] Livebuffer-plugin

    Zitat von CafeDelMar

    Daher kam der Vorschlag, die Live-Buffer-Bedienung erst mit dem Drücken der Pause-Taste zu starten. Ab diesem Zeitpunkt liegt eh eine temporäre Aufnahme vor, die nur um einen gewissen Vorlauf ergänzt werden müsste.


    Das widerspricht sich doch: Wenn es einen Vorlauf für temporäre Aufnahmen geben soll, dann muss der Livebuffer die ganze Zeit arbeiten und nicht erst, wenn die Pausetaste gedrückt wird. Der kann ja nicht hellsehen. Und wenn es eh schon einen Vorlauf gibt, dann spricht mMn auch nichts dagegen, dass man auch ohne Pausetaste da drin scrollen kann.


    Ich glaube, du meinst eher, dass beim Start einer Sofortaufnahme der Livebuffer mitgenutzt werden könnte? Das habe ich eigentlich unter "Nachträgliche Aufnahme einer ganzen Sendung" verstanden, stelle es mir aber im Vergleich zu den anderen Punkten aufwendig und alles andere als minimalinvasiv vor. Zur Abstimmung stehen sollte es natürlich trotzdem.

  • [Wunschkonzert] Livebuffer-plugin

    Zitat von seahawk1986

    Ja. Einfach neuen Thread erstellen und als Umfrage aufsetzen...


    Dann sollten wir das "Wunschkonzert" nun nach 10 Seiten mal eingrenzen und herausfinden, welche Funktionen denn tatsächlich wichtig sind. Ansonsten wird diese Diskussion ewig dauern und niemand wird sich trauen, mit der Entwicklung anzufangen, da das Ergebnis ja vielleicht unbefriedigend sein könnte.


    Ich kenne es aus anderen Foren so, dass eine einmal gestartete Umfrage nicht mehr geändert werden kann, deswegen stelle ich sie hier zur Diskussion. Die Reihenfolge der Fragen habe ich mehr oder weniger zufällig gewählt.



    Änderungsvorschläge?

  • [Wunschkonzert] Livebuffer-plugin

    2

    Zitat von gda

    Dieser ganze Thread ist gestartet worden wegen eines Patches, den wir bei uns raus genommen haben, der gerade für diesen Sonderfall gemacht wurde. Alle die diesem Patch nachweinen, wollen diesen Sonderfall.


    Beim Lesen des Threads hatte ich eher den Eindruck, dass es den meisten eher um die Möglichkeit des spontanen zurückspulen ging, die ebenfalls durch diesen Patch verschwunden ist. Meine Vorstellung ist aber ja im Prinzip auch nur eine (vermutlich einfacher zu implementierende) Teilmenge des Problems.


    Lässt dieses Forum wohl Umfragen zu?


    Zitat von hotzenplotz5

    so in der art war er mal im vdr paket in yavdr (jetzt nicht mehr)
    https://github.com/yavdr/vdr/blob/573b60…fer12-rmm.patch


    Ist das der Patch den gda meint? Warum ist er rausgeflogen? Am Anfang des Threads stand mal was davon, dass er mit 1.7 nicht mehr stabil gewesen sei, aber was genau war das Problem?


    Wir können diese Korrespondenz auch gerne per PM fortführen, wenn hier jemand den Eindruck hat, dass wir uns wieder im Kreis bewegen.

  • [Wunschkonzert] Livebuffer-plugin

    Zitat von Cybso

    Ich habe mich mit dem VDR-Source bisher nur oberflächlich beschäftigt. Den Ringbuffer selbst einzubauen stelle ich mir recht einfach vor, wenn man die passende Stelle gefunden hat. Irgendwo müssen die Streamdaten ja an die dekodierende Einheit weitergegeben werden, vielleicht kommt dort sogar sowieso schon ein kleiner Buffer zum Einsatz?! Ansonsten schreibt man an der entsprechenden Stelle die Daten halt in den Buffer rein und liest sie dem Zeitcode entsprechend von einer anderen Position wieder aus.


    Ok, streicht das "einfach". Ich hab mir gerade die Methode cDvbPlayer::Action in der Datei dvbplayer.c angeschaut. Das scheint schon die richtige Stelle zu sein, aber... das ist ein 300-Zeilen-Codeblob mit ein paar Zeilen Kommentare :-/ Mag mir jemand vielleicht den Datenfluß genauer erklären, ggf. auch im Chat (allerdings nicht mehr heute)?

  • [Wunschkonzert] Livebuffer-plugin

    Zitat von kls

    Das passiert dir bei einem "Live-Buffer" im RAM genauso, wenn aus irgend einem Grund VDR neu startet.
    Wer einen Live-Buffer im RAM fordert, wird diesen Wunsch sofort verfluchen, wenn er ihn das erste Mal verloren hat.


    Ne, eben nicht. Ich habe in der Definition ja beschrieben, dass die Umwandlung eines Livebuffers eigentlich nur für wenige Fälle relevant ist, das wichtigste ist die Möglichkeit, jederzeit zurückspringen zu können. Deswegen wird aus einem Livebuffer nach diesem Konzept niemals eine Aufnahme werden; wenn man dieses will muss man sie manuell starten und dann erfolgt sie auf dem ganz normalen Weg(*). Also auch kein Frust. Außer man lässt den Buffer solange auf Pause stehen bis der RAM voll ist, aber bei 4 GB passen da mehrere Stunden SD und doch noch eine ganze Menge HD-Material rein.


    Zitat von gda

    Nur zu, wir sind die Letzten die sich gegen eine vernünftig implementierte Lösung sperren würden.


    Gibt es irgendwo eine Übersicht über den Aufbau des Quellcodes? Es fällt mir schwer, den Einstieg zu finden, um einen Proof-of-Concept entwickeln zu können.


    Edit 1: *) Will man unbedingt die Möglichkeit erhalten, den Inhalt des Buffers ebenfalls in die Aufnahme einfließen zu lassen, müsste man der Aufnahmefunktion aber auch nur einen Pointer auf die Livebuffer-Datenstruktur mitgeben, damit sie diese Daten vor den aktuellen Stream hängen kann. Aber das fände ich wieder sehr unsauber und wäre auch nur in dem einen Sonderfall "Ich gucke gerade eine Sendung und stelle fest, dass sie doch recht interessant ist, aber es gibt keine Wiederholung" relevant.


    Edit 2: Wenn der VDR neu gestartet wird, dann wäre in der Aufnahme so oder so eine Lücke drin. Ich glaube, diesen Fall kann man getrost ignorieren. Ich glaube auch nicht, dass besonders viele Anwender damit rechnen würden, in einem solchen Fall den Livebuffer zu behalten.

  • [Wunschkonzert] Livebuffer-plugin

    Ich habe mir gestern abend den ganzen Thread durchgelesen und mir dann im Bett meine eigenen Gedanken gemacht. Auch wenn einiges davon redundant zu dem bereits hier gesagten ist, würde ich mich freuen, wenn sie nicht ganz unbeachtet blieben.


    Was erwarte ich von einem Livebuffer?


    Von einem Livebuffer erwarte ich, dass ich die Wiedergabe jederzeit anhalten kann. Darüber hinaus, dass ich einige Minuten zurück spulen kann, wenn ich spontan abgelenkt wurde oder das Ende einer Werbepause auf dem Klo verpasst habe. Außerdem sollte man durch vorspulen zum Beispiel während einer Werbepause nahtlos zurück in die Livewiedergabe gelangen können.


    Angesprochene Punkte wie eine Anpassung der EPG-Anzeige oder das direkte Umwandeln in eine Aufnahme sind für mich unnötiger Luxus, den die meisten glaub ich auch gar nicht so sehr haben wollen.


    Was kann VDR?


    VDR kann durch einen Druck auf die Pausetaste das Livesignal aufzeichnen, in den Wiedergabemodus wechseln und innerhalb dieses Navigieren. Mit dem entsprechenden Patch (der bei mir übrigens nicht zuverlässig funktioniert) wird die Aufnahme beim Beenden des Wiedergabemodus gelöscht.


    Was ist kaputt?


    Das ganze Konzept. Ein Livebuffer ist keine Aufnahme, und die Verwendung der entsprechenden Routinen sorgt für jedemenge Nebeneffekte: Es gibt beim Starten und Beenden kurze Verzögerungen durch den Moduswechsel, die Tastenbelegung ändert sich für den Anwender unbemerkt, und wenn man Umschaltet ohne die Aufnahme zu Beenden sind bei DVB-S nur ein Bruchteil der Kanäle verfügbar. Besonders fies, wenn man eigentlich noch eine andere Aufnahme programmiert hat, die dann u.U. nicht oder verspätet startet.


    Für den normalen Anwender ist es zudem verständlicher, dass der Livebuffer beim Umschalten verloren geht, als dass er erst den Wiedergabemodus beenden und ggf. den Timer löschen muss.


    Um mal das andere, von MythTV implementierte Extrem zu betrachten: Alles ist eine Aufnahme. Ist meiner Meinung nach genauso kaputt, denn für Daten, die ich in 95% aller Fälle niemals brauche, wird die Festplatte belastet. Eine Ramdisk für die Live-Aufnahmen macht spätestens dann Probleme, wenn man eine getimerte Aufnahme live ansieht, da die Datei dann in der Ramdisk landet und beim Reboot weg ist (und/oder die Ramdisk irgendwann voll). Außerdem sorgt es dafür, dass der Kanalwechsel in MythTV extrem lange dauert.


    Und was denke ich?


    Meiner Meinung nach gehört der Livebuffer in einen Ringbuffer im Arbeitsspeicher, und zwar architektonisch so weit wie möglich nach Vorne! Bei einer normalen VDR-Konfiguration also irgendwo direkt vor der Weitergabe der Daten an den TV-Ausgang bzw. libxineoutput etc., bei einer streamdev-Konfiguration in den Clienten, bei einer XBMC-PVR-Installation ins PVR-Addon von XBMC. Würde man das irgendwo tief in den Server verstecken kriegt man unschöne Sonderfälle z.B. bei gleichzeitigen Aufnahmen des selben Kanals rein, und wenn viele Clients auf dem selben Server arbeiten könnte sie dessen Ringbuffer mal eben fluten, obwohl sie selbst vielleicht noch viel Arbeitsspeicher frei hätten.


    Implementierung


    Ich habe mich mit dem VDR-Source bisher nur oberflächlich beschäftigt. Den Ringbuffer selbst einzubauen stelle ich mir recht einfach vor, wenn man die passende Stelle gefunden hat. Irgendwo müssen die Streamdaten ja an die dekodierende Einheit weitergegeben werden, vielleicht kommt dort sogar sowieso schon ein kleiner Buffer zum Einsatz?! Ansonsten schreibt man an der entsprechenden Stelle die Daten halt in den Buffer rein und liest sie dem Zeitcode entsprechend von einer anderen Position wieder aus.


    Die entsprechenden Tastenfunktionen bräuchten dann Zugriff auf die Datenstruktur, die den Livebuffer und die aktuelle Position verwaltet. "Pause" müsste ein Flag setzen, dass den aktuellen Frame in ein Standbild umwandelt oder Null-Bytes sendet oder etwas in der Art. "Zurück" würde die aktuelle Position nach hinten verschieben, aber maximal bis zur Größe des Livebuffers (beim Füllen des Buffers müsste diese Position natürlich angepasst werden, wenn der Ringbuffer vollständig gefüllt wurde). "Vorwärts" würde die aktuelle Position nach vorne Verschieben, aber ebenfalls nur bis zum maximalen Füllstand des Buffers.

  • Neues XBMC für yaVDR 0.4 in testing

    Zitat von gda


    Das geht auch einfacher. Im PPA unstable-xbmc-p8 sind die selben Pakete, aber völlig ohne Patches (bis auf unseren RSS-Patch). Vom Namen des PPAs nicht irritieren lassen. War eigentlich für Tests im Team gedacht, ist dort allerdings nicht auf Resonanz gestoßen.


    Ok, das war mir neu. Allerdings würde mich ja interessieren, ob das Problem auch für andere an *exakt* diesem Patch liegt.

  • Neues XBMC für yaVDR 0.4 in testing

    Über Ostern habe ich es nicht geschafft, aber gestern abend bzw. heute morgen. Ich habe angefangen, die Unterschiede zwischen dem funktionierenden team-xbmc-XBMC und dem yavdr-testing-XBMC zu analysieren. Das hätte auf meiner veralteten Hardware eine Ewigkeit dauern können (ein vollständiger Build braucht ca. 3 Stunden), aber ich hatte wohl einen Lucky Shot, denn der erste entfernte Unterschied war die Ursache. Zumindest für mich, aber die Stelle scheint nicht treiberspezifisch zu sein.


    Der Patch debian/patches/02-ReferenceClockHang, der in team-xbmc nicht vorkommt.


    Vielleicht kann man es auch als "educated guess" bezeichnen, denn ironischerweise steht in dem Patch:


    Zitat

    + // we are stopping the videoreferenceclock before start to change screenmode
    + // Intel and AMD drivers need this to not make the referenceclock thread hang


    Ich möchte andere bitten, XBMC ebenfalls ohne diesen Patch zu testen! Zuerst auf dem System auf die defekte Version wechseln, falls man gerade z.B. die team-xbmc-Version verwendet. Anschließend mit folgenden Befehlen ein neues Paket bauen:


    1. Die Buildumgebung installieren, sofern noch nicht vorhanden:

    Code
    $ sudo apt-get install build-essential gcc g++ devscripts


    2. Den Quelltext und die zur Kompilierung notwendigen Abhängigkeiten installieren:

    Code
    $ sudo apt-get build-dep xbmc
$ apt-get source xbmc


    Das sollte in etwa folgende Dateien herunterladen. Je nach verwendeter Version mögen sich die Namen im Detail unterscheiden:


    Code
    $ ls
xbmc-11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc/
xbmc_11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc.orig.tar.gz
xbmc_11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc-yavdr6~natty.debian.tar.gz
xbmc_11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc-yavdr6~natty.dsc


    Im Verzeichnis xbmc-11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc/ befindet sich der ausgepackte Quellcode, bei dem bereits alle Patches angewandt wurden! Deshalb nun den in Frage stehenden Patch rückgängig machen:


    Code
    $ cd xbmc-11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc/
$ patch -R -p1 < debian/patches/02-ReferenceClockHang
patching file xbmc/guilib/GraphicContext.cpp


    Nun den Quelltext kompilieren und ein neues .deb erstellen. Damit das selbsterstellte Paket nicht sofort wieder vom nächsten "apt-get upgrade" überschrieben wird fügt die erste Zeile eine neue Unterversion hinzu. Erst bei einer tatsächlich neueren Version wird das Paket ersetzt werden:


    Code
    $ dch -l-custom "debian/patches/02-ReferenceClockHang entfernt"
dch warning: your current directory has been renamed to:
../xbmc-11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc-yavdr6~natty
dch warning: no orig tarball found for the new version
$ dpkg-buildpackage -rfakeroot -uc -b
...viele viele Ausgaben...


    Bin gespannt auf eure Berichte!°


    Wenn alles erfolgreich durchgelaufen ist, dann wurde eine neue .deb-Datei erstellt, die nun installiert werden kann:


    Code
    $ sudo dpkg -i ../xbmc_11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc-yavdr6\~natty-custom1_all.deb ../xbmc-bin_11.0-pvr+yavdr2-odk73-eden-git20120402.0b73bfc-yavdr6\~natty-custom1_i386.deb

  • suspendoutput: enable shutdown code

    Petri Hintukainen (the author of suspendoutput) wrote me today that this code part has been disabled because it "does not work with recent vdr versions". Well, it works for me, but maybe you found what he meant. He also suggests that "updating it
    from some recent vdr.c might work".

  • suspendoutput: enable shutdown code

    When suspendoutput is enabled, VDR (at least a yaVDR installation) will not shutdown after MinUserInactivity minutes passed. I tried to contact the developer but he didn't answer. In the plugin's code there was a snippet that seems to do the job but it was disabled.


    The attached patch enables this code and adds a menu item to activate or deactivate it. Furthermore, it corrects the indention in this section. It is written against vdr-plugin-suspendoutput-1.0.1.


    This is not tested very much, but for two days until now it "works for me".

  • Neues XBMC für yaVDR 0.4 in testing

    Wenn es im einen Zweig geht und im anderen nicht, dann müsste man doch mit git-bisect dem Problem auf die Spur kommen können... hat das schonmal jemand hier probiert?


    Wenn das Problem bis zum Osterwochenende nicht gefunden wurde und Frau und Kind mich lassen werde ich mich dann mal selbst dransetzen.

  • Neues XBMC für yaVDR 0.4 in testing

    Hier blieb das Update auch ohne Effekt:


    Code
    apt-cache policy xbmc
xbmc:
  Installiert: 2:11.0-pvr+odk70-eden~git20120325.37d89f7-0yavdr2~ppa1+odk70~natty
  Kandidat:    2:11.0-pvr+odk70-eden~git20120325.37d89f7-0yavdr2~ppa1+odk70~natty
  Versionstabelle:
 *** 2:11.0-pvr+odk70-eden~git20120325.37d89f7-0yavdr2~ppa1+odk70~natty 0
       1002 http://ppa.launchpad.net/yavdr/testing-xbmc/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status


    Edit: ppa:team-xbmc/ppa (ohne PVR-AddOn) funktioniert übrigens! Da ich das PVR in diesem Setup eh nicht brauche werde ich nun darauf umsteigen.

  • Neues XBMC für yaVDR 0.4 in testing

    Das nvidia-Problem betrifft mich sicher nicht, ich hab ne Intel-Grafikkarte (ich weiß, von yaVDR nicht offiziell supported, aber möglich). Dennoch scheint es mit dem GLX zu tun zu haben, denn wenn ich dem VDR-Benutzer die "video"-Berechtigung wegnehme (und damit die Möglichkeit, per OpenGL darzustellen) beendet sich XBMC normal.

  • Neues XBMC für yaVDR 0.4 in testing

    Zitat von seahawk1986


    Da unter yaVDR das der einzige User ist, der XBMC nutzt, würde ich den Pfad fest setzen und statt

    Code
    ~/.xbmc/userdata/guisettings.xml


    das nehmen:

    Code
    /var/lib/vdr/.xbmc/userdata/guisettings.xml


    Dann muss jedoch auch die Zeile "kill -9 $PPID" durch "killall -9 xbmc.bin" ersetzt werden, da das Script sonst die eigene Loginshell als Elternprozess töten dürfte.

  • Neues XBMC für yaVDR 0.4 in testing

    Folgender Workaround beendet XBMC bei mir zuverlässig, wenn auch mit einer kleinen Einschränkung:


    1. Die Datei /usr/local/bin/kill-xbmc.sh mit folgendem Inhalt anlegen:

    Bash
    #!/bin/sh


(sleep 5 && (
    sed -i -s 's~<screenmode>WINDOW</screenmode>~<screenmode>DESKTOP</screenmode>~' ~/.xbmc/userdata/guisettings.xml 
    kill -9 $PPID
)) &


    2. Die Datei ausführbar machen:

    Code
    $ sudo chmod 0755 /usr/local/bin/kill-xbmc.sh


    3. Das Confluence-Theme modifizieren, damit dieses Script beim Beenden aufgerufen wird. Dazu die Datei /usr/share/xbmc/addons/skin.confluence/720p/DialogButtonMenu.xml als root bzw. mit sudo in einem Editor öffnen und die folgende Stelle suchen:



    Vor der Zeile "<onclick>XBMC.Quit()</onclick>" wird nun die neue Zeile "<onclick>System.Exec("/usr/local/bin/kill-xbmc.sh")</onclick>" eingefügt, so dass der entsprechende Abschnitt nun so aussieht:



    Erklärung und Einschränkungen


    Das Script legt sich 5 Sekunden lang schlafen. Anschließend sendet es dem Elternprozess (=xbmc.bin) ein kill-Signal.


    Bei mir gab es die Nebenwirkung, dass XBMC sich selbst auf den Fenstermodus umgeschaltet hat. Ob das ein Problem in diesem Verfahren ist, oder ob das vielleicht sogar mit dem eigentlichen Absturz zusammenhängt - keine Ahnung. Die "sed"-Anweisung im Script sorgt deshalb dafür, dass der Vollbildmodus wieder in der guisettings.xml eingetragen wird.


    Wenn ein XBMC-Update kommt, dann wird die veränderte Datei überschrieben werden. Man muss dann also die neue onclick-Anweisung wieder einfügen. Am schönsten wäre es, ein AddOn zu haben, dass auf das OnQuit-Event horcht und dann das kill einleitet, aber ich habe in der Plugin-Dokumentation keine Erklärung gefunden, wie man sich in das Eventsystem von XBMC einhängen kann.