Projektidee: Python-Einbettung in den VDR

voeck · 6. Februar 2012

Hallo,

ich bin erst seit kurzem VDR-Nutzer aber schon ziemlich begeistert. Und nachdem ich gesehen habe, wie einfach er sich durch Plugins erweitern lässt, habe ich auch gleich mit meiner ersten Plugin-Idee begonnen, die ich einmal kurz vorstellen möchte. Und zwar plane ich einen Python-Interpreter in den VDR einzubetten. Das Ziel wäre, dass mein Plugin beim Start alle Python-Module in CONFDIR/plugins/python/ importiert und dann einfach die normalen Plugin-Methoden (Initialize, Start, Housekeeping...) an die Python-Module weiterleitet und dort dann einfach die entsprechende Funktion aufruft - jedenfalls so weit das sinnvoll ist. Außerdem werde ich die VDR-API in Form eines Python-Moduls bereitstellen, das im eingebetteten Interpreter einfach importiert werden kann. Auf diese Weise sollten sich (fast) vollwertige VDR-Plugins in Python entwickeln lassen. Das Plugin wäre also eher eine Art Meta-Plugin.

Wie ist der Status des ganzen? Ein paar Tests haben gezeigt, dass sich der Python-Interpreter tatsächlich sehr einfach in den VDR einbetten lässt. Einfache Skripte werden auch anstandslos ausgeführt. Jedenfalls geben sie auf der Konsole die korrekten Ausgaben aus - VDR-Funktionalität gibt es allerdings noch nicht. Aber dafür werde ich nun versuchen die VDR-Klassen (höchstwahrscheinlich mit Boost.Python) einzubinden. Code zum Testen wird es geben, sobald man mit dem Ganzen was sinnvolles machen kann.

Ich freue mich aber über Feedback zu der Idee!

Grüße,
Sebastian

M-Reimer · 6. Februar 2012

Soweit mir bekannt gibt es da allgemeine Lösungen, die auch gleich optional andere Interpreter zulassen.

Oder um direkter zu werden: Ich konnte den Hype um Python nie verstehen. Bei einem eingebetteten Perl-Interpreter wäre ich aber dabei und würde, wo möglich, auch bei der Entwicklung helfen.

gda · 6. Februar 2012

Warum wollt ihr denn einen fetten Interpreter in den VDR würgen? Sicher ist es eine nette Idee mit einem Interpreter dichter an die VDR-Internas heranzukommen, aber das erreicht man doch viel einfacher und sicherer über das restfulapi-Plugin und einem separaten Interpreter. Das funktioniert dann auch gleich mit allen Interpretern.

Gerald

Keine_Ahnung · 6. Februar 2012

Zitat von gda

aber das erreicht man doch viel einfacher und sicherer über das restfulapi-Plugin und einem separaten Interpreter.

Das hat aber deutliche Einschränkungen um den VDR wirklich zu erweitern (im Plugin Sinn).

Spontan fallen mir viele Plugins ein die per Interpreter besser eingebunden wären als per nativen Plugin. Z.b. yacoto, mlist, ripit, eggtimer, cinebars, duplictes, filebrowser, noepgmenu, systeminfo, externalplayer usw.
Und viele Sachen lösen sich in Python auch wesendlich einfacher als in C.

Leider kann ein Plugin nur einen Mainmenüeintag (und einen Setupmenueintrag) erstellen. Das ist der Hauptnachteil dieser Idee. Denn so bekommt man auch diese Weise keine richtige VDR Einbindung der Python Plugins.

BTW: Es gibt AFAIK schon 2 Plugins die diese Idee (Interpreter einbinden) umsetzen.

cu

mini73 · 6. Februar 2012

Moin!

Interpreter einbinden ist zwar ein schönes Projekt, verstehen tue ich es aber auch nicht. Aber ich verstehe, wenn man ein Projekt hat, dass man gerne umsetzen möchte. So bin ich auch zu meinen ersten Plugins gekommen.
Also immer weiter damit!

(Offtopic)

Zitat von Keine_Ahnung

Leider kann ein Plugin nur einen Mainmenüeintrag (und einen Setupmenueintrag) erstellen. Das ist der Hauptnachteil dieser Idee.

Da ließe sich ja sicherlich was am vdr patchen, aber warum sollte ein Plugin mehr als einen Menüeintrag brauchen? Dahinter kann es ja ein eigenes komplettes Menü mit allem was es braucht erstellen.
Hast du ein Beispiel, damit ich mir was darunter vorstellen kann?

Lars.

gda · 6. Februar 2012

Zitat von Keine_Ahnung

Das hat aber deutliche Einschränkungen um den VDR wirklich zu erweitern (im Plugin Sinn).

Nö

Gerald

steffen_b · 6. Februar 2012

Zuallererst - lass dich nicht entmutigen. Ein funktionierendes aktives Plugin in der Richtung ist spannender als ein theoretisches ... und
"brauch ich nicht", "hatten wir schon" und "im Prinzip schon, aber" sind immer die ersten Antworten ...

Keine_Ahnung · 6. Februar 2012

Zitat von mini73

Da ließe sich ja sicherlich was am vdr patchen, aber warum sollte ein Plugin mehr als einen Menüeintrag brauchen? Dahinter kann es ja ein eigenes komplettes Menü mit allem was es braucht erstellen.
Hast du ein Beispiel, damit ich mir was darunter vorstellen kann?

Ich meinte, wenn dieses Plugin es erlaubt Plugins (die vollkommen unterschiedliche Aufgaben übernehmen) per Python zu implementieren, dann sollten diese Python Plugins auch per sepperaten Menüeinträgen erreichbar sein.

Das Problem hat man ja jetzt schon z.B. beim externalplayer Plugin, habe ich nur einen externalplayer konfiguriert (z.B. freevo) dann habe ich den Menüeintrag freevo im VDR (weil das externalplayer Plugin seinen Menüeintrag so nennt wie den externen Player (wenn es nur einen gibt)), konfiguriere ich freevo und links2 im externalplayer Plugin, dann habe ich im VDR den Menüeintrag "externalplayer" und darunter die Menüeinträge "feevo" und "links2". So kann man das VDR Menü nicht wirklich schön strukturieren.

Zitat von gda

Nö

Doch

cu

gda · 6. Februar 2012

Zitat von steffen_b

Zuallererst - lass dich nicht entmutigen. Ein funktionierendes aktives Plugin in der Richtung ist spannender als ein theoretisches ... und
"brauch ich nicht", "hatten wir schon" und "im Prinzip schon, aber" sind immer die ersten Antworten ...

Auch wieder wahr. All das habe ich auf der HaVUT gehört als ich meinen yaVDR-Prototypen vorgeführt habe. Ich habe mich auch nicht abhalten lassen, obwohl es keiner braucht und mag

Gerald

steffen_b · 6. Februar 2012

Zitat von mini73

Moin!
(Offtopic)

Da ließe sich ja sicherlich was am vdr patchen, aber warum sollte ein Plugin mehr als einen Menüeintrag brauchen? Dahinter kann es ja ein eigenes komplettes Menü mit allem was es braucht erstellen.
Hast du ein Beispiel, damit ich mir was darunter vorstellen kann?

Lars.

Ich könnte mir vorstellen das es sinning wäre mehr als ein "Python Plugin" zu betreiben

mini73 · 6. Februar 2012

Moin!

Zitat von Keine_Ahnung

Ich meinte, wenn dieses Plugin es erlaubt Plugins (die vollkommen unterschiedliche Aufgaben übernehmen) per Python zu implementieren, dann sollten diese Python Plugins auch per sepperaten Menüeinträgen erreichbar sein.

Ach ja, klar, so weit hatte ich noch nicht gedacht.

Lars.

voeck · 6. Februar 2012

Ich weiß, dass so eine Python-Lösung kein ressourcenschonender Weg ist. Aber ich denke, dass es dennoch oft Situationen gibt, in denen man
"mal eben schnell" etwas machen will. Und das ist dann mit einem Skript in der Regel deutlich schneller und einfacher gemacht.

Das Problem mit dem Menüpunkt ist mir auch klar. Deshalb sagte ich ja auch nur "fast" vollwertig. Aber ich habe gerade mal einen kurzen Blick in die plugin.c geworfen und frage mich gerade, was passiert denn, wenn ich das Plugin einfach mehrfach lade? Also etwa so: -P"python skript1.py" -P"python skript2.py". Nach meinem Verständnis der dlopen-Manpage wird die Bibliothek dann nur einmal geladen. Aber der VDR erstellt zwei Plugin-Objekte, womit ich dann doch auch zwei Menüeinträge hätte. Oder übersehe ich da gerade etwas?

Zitat von Keine_Ahnung

BTW: Es gibt AFAIK schon 2 Plugins die diese Idee (Interpreter einbinden) umsetzen.

Welche sind das? Ich konnte das scripting-Plugin finden, das aber eingeschlafen zu sein scheint und bisher auch nur Ruby unterstützt. Ich kann mir auch vorstellen Code zu einem existierenden Projekt beizutragen. Deshalb wollte ich die Idee ja auch erstmal hier vorstellen, bevor ich das Rad wieder zweimal erfinde.

M-Reimer · 6. Februar 2012

Das Scripting-Plugin verwendet "SWIG", was auch die "Universallösung" für Scripting ist, deren Name mir nicht einfallen wollte:

http://de.wikipedia.org/wiki/SWIG

Kann unter anderem auch Python und damit wäre es dann tatsächlich auch möglich Perl zu unterstützen.

Wie schon erwähnt: Von Python halte ich persönlich nicht viel. Wovon ich aber schon länger träume ist eine Lösung um vom VDR aus Perl-Scripte zu starten und damit Zugriff auf die, für (langsame) Script-Plugins interessanten, Interfaces zu bekommen. Mit SWIG könntest du zumindest die Basis für die Unterstützung von einer kleine Auswahl von Scriptsprachen schaffen.

voeck · 6. Februar 2012

Ich kenne SWIG sogar einigermaßen. Vor ein paar Jahren habe ich es schon einmal für ein paar PHP-Module verwendet. Ich hatte es auch als Alternative zu Boost.Python in Betracht gezogen. Aber da ich erst nur an Python hatte, entschied ich mich ursprünglich dagegen. Aber ich sehe durchaus die Vorteile so einer flexiblen Lösung. Daher könnte ich mir auch vorstellen SWIG nochmal eine Chance zu geben. Vielleicht ließe sich das Ganze sogar in die existierenden Lösungen integrieren und später sogar auf Perl erweitern.

geronimo · 6. Februar 2012

Hi,

ich hatte auch erst Bauchweh, als ich den Thread las.

Mein Favorit wäre auch perl - zumal das bei jedem Linux zur Grundausstattung gehört. Da muss man nix extra installieren.
Tja und python ist schon ne fette Angelegenheit - auch wenn es nicht wirklich mehr als perl kann.

Allerdings habe ich auch Verständnis dafür, dass Neueinsteiger sich eher mit python anfreunden, als mit perl (ist ja schließlich schon ein alter Zopf - auch wenn perl immer noch das Zeug hat, anderen Scriptsprachen den Schneid abzukaufen )

Gruß Gero

P.S. allerdings bin ich auch dafür, dass wenn man die Möglichkeit schafft, Scripte wie Plugins zu behandeln, dann sollte es auch für die Script-Plugins möglich sein, Toplevel-Menüeinträge zu erhalten, bzw. zu erstellen.

voeck · 6. Februar 2012

Hallo,

Ich wollte hier eigentlich keine Diskussion über die beste Skriptsprache auslösen. Da kann man ja bekanntlich endlos streiten.

Aber vielleicht kann man sich ja einigen, dass man die ganze Sache so flexibel wie möglich machen sollte. Dann hätte man eine Basis auf der man verschiedene Skript-Plugins für unterschiedliche Sprachen entwickeln kann. Also praktisch so wie es beim existierenden "scripting-Plugin" schon angedacht war. Obwohl es vermutlich besser wäre, nur eine Sprache pro Plugin zu unterstützen.

Sebastian

geronimo · 6. Februar 2012

Zitat

Ich wollte hier eigentlich keine Diskussion über die beste Skriptsprache auslösen.

Ok, so will ich auch nicht verstanden werden.

Primär geht es mir um die Frage, warum einen neuen Interpreter installieren.
Nicht jeder will nen fetten HD-VDR aufziehen, mit ner Riesen Systemplatte.

Auch wenn ich zu alt für Python-Kiddies bin, LinVDR hatte sich zum Ziel gesetzt, ein schlankes VDR-System zu sein, welches man zur Not auch in Silizium gießen könnte
Gut, LinVDR ist schon lange passe, aber ich bin immer noch ein Fan dieser Idee.
Deshalb finde ich, dass man als erstes versuchen sollte, mit dem auszukommen, was das System an Möglichkeiten bietet.
Perl gehört zu jedem IX-System von Haus aus dazu - weshalb also nicht perl nehmen? Braucht es unbedingt andere Sprachen, nur weil die gerade HIP sind?

Wie gesagt, mir geht es nicht darum, über die Möglichkeiten der Sprache zu debattieren.

Vor vielen Jahren habe ich bei einer Firma gearbeitet, bei der es nur Windows-Arbeitsplätze gab. Trotzdem hat der Entwicklungschef von jedem verlangt, den vi zu erlernen.
Nicht weil der so toll ist - ganz bestimmt nicht.
Das einzige stichhaltige Argument war: den gibt es auf jedem noch so alten Unix.
Wenn du also zu einem Kunden mit Unix musst, dann kannst du dich immer auf den vi verlassen.
Ich kenne Admins, die installieren auf jedem Kunden-Windows einen gvim

Auch wenn es anfangs vielleicht lästig ist - das Prinzip gilt auch heute noch.
... und nur so möchte ich verstanden werden

Gruß Gero

Keine_Ahnung · 6. Februar 2012

Python ist doch nicht viel. Das reduziert sich auf 2-3 MB. Andere Plugins bringen mehr an Bilddateien mit

Das schöne an Python ist das man da ernsthaft was mit machen kann und das der Einstieg trozdem sehr leicht fällt (und Python einen da gleich vom Pfushen abhält).

cu

geronimo · 7. Februar 2012

Zitat

Python ist doch nicht viel. Das reduziert sich auf 2-3 MB.

Lach - das mag wohl auf den reinen Interpreter zutreffen.

Als ich mich letztens mit den ID3-Tags rumschlug, habe ich auch einige python-Anwendungen ausprobiert.
Was die alles nach installierten, bzw. an python-Addons voraussetzten, das sorgte dann schon dafür, dass mir die Kinnlade runterfiel.

Und das schlimmste von allem - die Installation des ganzen Python-Rattenschwanz war zu nix gut. Das einzige, was ich nach wie vor nutze ist kid3 und amarok - beides sind KDE-Anwendungen, als C++ oder so. Die python-Teile haben keine Tags gefunden.
Da frage ich mich wirklich - was so toll an python sein soll

Gruß Gero

M-Reimer · 7. Februar 2012

Zitat von Keine_Ahnung

Das schöne an Python ist das man da ernsthaft was mit machen kann und das der Einstieg trozdem sehr leicht fällt (und Python einen da gleich vom Pfushen abhält).

Ich finde die Art, in Python zu programmieren, sagen wir mal "gewöhnungsbedürftig". Und auch in Perl ist man schnell eingestiegen. Was ich mit der Sprache schon alles in wenig Codezeilen und kürzester Zeit gemacht habe, da möchte ich garnicht dran denken, wie lange das unter C(++) gedauert hätte. Vor allem die Hash-Arrays haben es mir angetan. Damit kann man tolle Sachen machen! Wenn man dann noch GTK ins Boot nimmt, dann gehen in Perl auch schöne GUIs. Praktisch ist auch, dass man, trotz Scriptsprache, Zeiger auf Variablen generieren kann.

Ich stimme aber zu, dass eine Diskussion um die "richtige Scriptsprache" hier zu weit führt. Wegen mir kann eine solche Diskussion gerne in einem speparaten Thread fortgeführt werden.

Einigen wir uns für die Diskussion über eine Script-Einbettung in den VDR einfach darauf, dass es sinnvoll wäre, mehr als eine Sprache zu unterstützen.

Zurück zum Topic:
Leider bin ich bei SWIG nie wirklich durchgestiegen. Ein Buch zum Thema "Perl Einbettung" habe ich zwar (damals extra gekauft, weil ich den VDR um Perl erweitern wollte) aber das Thema war mir dann zu komplex um es so ohne weitere Hilfe umsetzen zu können. Wenn mir voeck aber etwas zur Seite steht, würde ich bei einer Perl-Anbindung gerne helfen. Ich wäre allerdings dafür alles in einem Source-Tree zu halten, denn dank SWIG wird es zwangsläufig darauf hinauslaufen, dass einige Daten "allgemeingültig" für alle gewünschten Scriptsprachen sind. Wäre irgendwie unsinnig die dann zwischen getrennt gepflegten Plugins immer hin und herzusyncen. Ich bin für bedingte Kompilierung und eine "Make.config" für das Plugin. So könnte sich jeder die Scriptsprachen aktivieren, die er nutzen will.

Projektidee: Python-Einbettung in den VDR

Jetzt mitmachen!

Teilen