[ANNOUNCE] vdr-scripting 0.0.1 - proof-of-concept release

  • Bei der Überlegung, ob ich das Vodcacher-, Podcatcher- und Menuorg-Plugin auf projects.vdr-developer.org einstellen sollte, bin ich zu dem Schluss gekommen dass ich nicht wirklich sonderlich motiviert bin, diese Plug-ins weiterzuentwickeln. Einer der Gründe dafür ist, dass C/C++ im Vergleich zu C#, Ruby, Python oder <HIER deine Lieblingssprache einfügen> einfach nicht so viel Spaß macht.


    Kurzerhand habe ich deshalb mal ein altes Projekt aus der Schublade gezogen, welches ich da schon seit Jahren rumliegen habe:


    Ein VDR-Plugin das es ermöglicht, Plugins in einer dynamischen Skriptsprache zu schreiben.


    Der Hintergedanke dabei ist, das Vodcatcher, Podcatcher und Menuorg-Plugin vollständing in einer Skriptsprache neu zu implementieren.


    Das Scripting-Plugin soll als Host für Script-Plugins fungieren, die Zugriff auf die meisten Funktionen haben sollen, wie ein gewöhnliches in C++ geschriebenes Plugin auch. Inwieweit das realisierbar ist und wo ich dabei an Grenzen stoße, ist mir dabei allerdings noch nicht ganz klar.


    Den Anfang habe ich erstmal mit einem proof-of-concept-Release für Ruby gemacht. Bis auf weiteres wird es auch bei Ruby bleiben. Eventuell wird es später aber auch eine Python-Alternative geben. Möglich wäre es jedenfalls, beides unter einen Hut zu bringen, da ein Großteil der Schnittstelle zwischen VDR und Script-Sprache von SWIG bereitgestellt wird. Der Teufel steckt halt im Detail - Memorymanagement, die Client-API u.s.w.


    Wer das ganze mal testen möchte:


    http://projects.vdr-developer.…/list_files/plg-scripting


    Viel kann das Plugin allerdings noch nicht. Es werden lediglich einfache OSD-Menus unterstützt. Als Beispiel-Skripte liegen das obligatorische "Hello World" und ein simpler RSS-Feed-Leser bei.


    Ein paar Bugs sind besteimmt auch drin, aber für einen ersten Eindruck sollte es reichen. Anregungen, Vorschläge, Wünsche oder konkrete Hilfe sind jederzeit willkommen! (Am besten gleich in den Bugtracker eintragen!)


    [Blockierte Grafik: http://projects.vdr-developer.org/attachments/download/61]

  • Hi Tobi,


    ziemliche coole Idee. Respekt!


    Wenn das ganze gut funktioniert, könnte das zu einem kleinen Boom bei der VDR-Pluginentwicklung führen :)


    Ich persönlich würde aber lieber Groovy oder JAVA nutzen wollen.


    Bin gespannt wie es weiter geht.


    Gruß
    Ranga

    - yavdr 0.6.1 -


    . . : : ASUS AT3IONT-I , 2 GB RAM : : Mystique Satix Dual S2 ::..
    ..:: Silverstone ML02B-MXR :: Samsung 1,5TB Eco Green : : Logitech Harmony 1100::..

  • Für Java kannst du JNI nutzen, dann brauchst du aber zwangsläufig trotzdem die JavaVM, was aber nicht schlimm ist. ich würde auch lieber java nutzen. Aber mit JNI dürfte man relativ schnell eine Schnittstelle zum VDR hinbekommen.


    Medion Digitainer; AsRock B75 Pro3-M, Celeron G540; Kingston Value 4GB
    Samsung SpinPoint 250GB 2,5"; Samsung WriteMaster DVD-Brenner;
    TT-S2-6400, 2x TT-S2-1600, Ubuntu 12.04 mit YaVDR-Paketen. VDR 1.7.27, UPnP/DLNA-Plugin

    2 Mal editiert, zuletzt von methodus ()

  • Ich erhalte die folgende Fehlermeldung


    Code
    g++ -fPIC -g -O2 -march=prescott -fomit-frame-pointer -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DUSE_CHANNELSCAN -DUSE_CMDCTRL -DUSE_CMDSUBMENU -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DELTIMESHIFTREC -DUSE_DDEPGENTRY -DUSE_DOLBYINREC -DUSE_DVBPLAYER -DUSE_DVBSETUP -DUSE_DVDARCHIVE -DUSE_DVLRECSCRIPTADDON -DUSE_DVLVIDPREFER -DUSE_DVLFRIENDLYFNAMES -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_IPTV -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_LIRCSETTINGS -DUSE_LIVEBUFFER -DUSE_LNBSHARE -DUSE_MAINMENUHOOKS -DUSE_SETUP -DUSE_NOEPG -DUSE_OSDMAXITEMS -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_PREMIEREEPGFIX -DUSE_ROTOR -DUSE_SETTIME -DUSE_SOURCECAPS -DUSE_SORTRECORDS -DUSE_SWITCHTIMER -DUSE_SYNCEARLY -DUSE_TIMERCMD -DUSE_TIMERINFO -DUSE_VALIDINPUT -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"scripting"' -DRUBY_EMBEDDED  -I/usr/local/src/DVB/include -I/usr/local/src/DVB/include -I. -I/home/ralf/src/vdr-1.6.0/include -I/usr/local/src/DVB/include `/usr/bin/ruby1.8 ruby-config.rb --cflags` swig/vdr_wrap.cc -o swig/vdr_wrap.o
    swig/vdr_wrap.cc: In function »void SWIG_RubyInitializeTrackings()«:
    swig/vdr_wrap.cc:1029: Fehler: »_mSWIG« wurde in diesem Gültigkeitsbereich nicht definiert
    make: *** [swig/vdr_wrap.o] Fehler 1


    was fehlt denn hier? Habe Ruby und Swig installiert.


    Gruß
    Ranga

    - yavdr 0.6.1 -


    . . : : ASUS AT3IONT-I , 2 GB RAM : : Mystique Satix Dual S2 ::..
    ..:: Silverstone ML02B-MXR :: Samsung 1,5TB Eco Green : : Logitech Harmony 1100::..

  • Zitat

    Originally posted by steffen_b
    Genau umgedreht gabs das ja schonmal :D Dachte mir grade gabs das nicht schonmal, aber die Idee ist ne andere:
    http://www.udo-richter.de/vdr/osdserver.html


    Ist doch im Prinzip das selbe (oder verstehe ich da den Ansatz falsch?). Nur das der OSD Server nur ne Schnitstelle zur GUI bietet und gepollt werden will.


    Ansonsten, super Idee, warte gespannt und freudig auf die Python Version. :)


    cu

  • Ranga: Kann eigentlich nur an der SWIG -Version liegen. Bei mir: 1.3.36. Welche Version verwendest du? Schick mir bitte auch mal die generierte Datei swig/vdr_wrap.cc.


    steffen_b: OSDServer ist auch ne feine Sache zumal man das Script dann auch "remote" laufen lassen kann. Ich möchte aber mit vdr-scripting aber noch ein Stück weiter gehen und mehr als nur das OSD für Skripte zur Verfügung stellen.


    Java wäre theoretisch sicher auch möglich, es gibt wohl auch ein JavaScript-Modul für SWIG, aber ich denke das ist sicher nicht ganz einfach.


    Für's erste habe ich mich halt für Ruby entschieden, da ich hier schon ein paar Erfahrungen mit dem Einbetten und dem Schreiben von C/C++-Erweiterungen habe. Außerdem finde ich Ruby ganz generell recht gut und es gibt eine Unmenge von libraries/Gem's, die ich bei anderen Skriptsprachen vermisse.


    Wenn in Version 1.0 alles so klappt, wie ich mir das vorstelle, werde ich dann mal versuchen auch Python zu integrieren. Wenn das auch klappt, sollte die Scripting-Engine soweit abstrahiert sein, dass auch andere Skript-Sparchen oder auch compilierte Erweiterungen (z.B. Mono/C#) möglich sind. Aber das ist noch Zukunftsmusik - erstmal sehen, wie weit ich mit Ruby komme.

  • Na dann viel Glück für dein Projekt, auch wenn wir da ein wenig konkurrieren. ;)


    Auch wenn ich deine Meinung zu C++ nicht teilen kann, es gibt Anwendungen, für die sich Skriptsprachen eher anbieten, und die Einstiegshürde wird dadurch niedriger.


    Lass dir aber aus Erfahrung sagen, dass eine gute Idee und reichlich Glückwünsche allein noch nicht allzu viele neue Entwickler motiviert. ;)



    Zitat

    Originally posted by Keine_Ahnung


    Ist doch im Prinzip das selbe (oder verstehe ich da den Ansatz falsch?). Nur das der OSD Server nur ne Schnitstelle zur GUI bietet und gepollt werden will.


    ... bisher nur zum GUI bietet - andere Dinge könnten integriert werden, wenn Bedarf besteht, nur fallen mir nicht allzu viele andere Dinge ein, die nicht schon per OSDServer oder SVDRP erreichbar sind. Außerdem pollt OSDServer nicht, dafür gibt es ein Event-System.


    Sonst ähneln beide Konzepte sich durchaus - mit den Perl-Bindings benutzt sich ein OSDServer-Menü schon kaum anders als ein scripting-Menü.


    Ein wesentlicher Unterschied: OSDServer-Skripte sind extern: Sie werden per commands.conf oder ähnlich gestartet, und können (bisher) keinen Mainmenu-Eintrag haben. In scripting starten die Skripte zusammen mit VDR.



    Gruß,


    Udo

  • Hi Tobi,


    Zitat

    Bei der Überlegung, ob ich das Vodcacher-, Podcatcher- und Menuorg-Plugin auf projects.vdr-developer.org einstellen sollte, bin ich zu dem Schluss gekommen dass ich nicht wirklich sonderlich motiviert bin, diese Plug-ins weiterzuentwickeln...


    Das ist aber Schade!


    Urig

    Zitat

    Lass dir aber aus Erfahrung sagen, dass eine gute Idee und reichlich Glückwünsche allein noch nicht allzu viele neue Entwickler motiviert.


    Beim x-vdr mache ich den System-Setup mit einem Bash Skript und dem OSDServer. Damit gehen schon komplexe Menüs und auch so Sachen wie Plugins kompilieren aus dem OSD :)


    Zitat

    Ein wesentlicher Unterschied: OSDServer-Skripte sind extern: Sie werden per commands.conf oder ähnlich gestartet, und können (bisher) keinen Mainmenu-Eintrag haben...


    Mainmenu-Eintrag geht mit dem Setup- und Menuorg-Plugin wunderbar. Schön wäre eine Möglichkeit wieder ins Menü zurück zu springen.


    Gruß
    Marc

  • Hi Tobi,


    Zitat

    Original von Tobi
    Ranga: Kann eigentlich nur an der SWIG -Version liegen. Bei mir: 1.3.36. Welche Version verwendest du? Schick mir bitte auch mal die generierte Datei swig/vdr_wrap.cc.


    habe Dir mal die generierte wrapperdatei per mail gesendet.


    Übrigens verwende ich swig 1.3.31 ist doch nicht so weit von 1.3.36 entfernt ...


    mal schauen, werde mal 1.3.36 probieren.


    Gruß
    Ranga

    - yavdr 0.6.1 -


    . . : : ASUS AT3IONT-I , 2 GB RAM : : Mystique Satix Dual S2 ::..
    ..:: Silverstone ML02B-MXR :: Samsung 1,5TB Eco Green : : Logitech Harmony 1100::..

    Einmal editiert, zuletzt von Ranga ()

  • Hier klappt das ganze auch nicht wirklich.



    Hast Du hier nen Link gesetzt /usr/bin/ruby1.8?


    Später, hat sich erledigt :schiel


    Code
    - RUBY ?= /usr/bin/ruby1.8
    +  RUBY ?= /usr/bin/ruby


    LG Ronny

    3 Mal editiert, zuletzt von ronnykornexl ()

  • mit der aktuellen swig Version 1.3.38 lässt es scih zumindest überetzen.


    Ich teste nun mal ein bisschen


    Gruß
    Ranga

    - yavdr 0.6.1 -


    . . : : ASUS AT3IONT-I , 2 GB RAM : : Mystique Satix Dual S2 ::..
    ..:: Silverstone ML02B-MXR :: Samsung 1,5TB Eco Green : : Logitech Harmony 1100::..

  • Zitat

    Originally posted by Urig
    ... bisher nur zum GUI bietet - andere Dinge könnten integriert werden, wenn Bedarf besteht, nur fallen mir nicht allzu viele andere Dinge ein, die nicht schon per OSDServer oder SVDRP erreichbar sind.


    Was ich bissher vermisste (nur so als Anregung falls es gefällt):


    Ein Fenster für die simple Ausgabe von ASCII Text vermisse ich (so wie es nach der Befehlsausführung eines commands.conf Befehls kommt).
    Man könnte das zwar auch zeilenweise in ein Menü schreiben, aber dann gibts ja wieder Probleme mit dem Zeilenumbruch.


    Und aus dem Bereich "wäre nett das zu habe" wäre es praktisch zu erfahlen wie breit eine Textzeile eigendlich ist (egal ob Pixel, Punkt oder was auch immer).
    Dazu dann eine Möglichkeit zu erfahren wie breit eine Zeichenkette ist.
    Das wäre z.B. für grafische Fortschrittbalken ganz nett. Dann müsste man nicht mit ausprobierten Konstanten arbeiten und die Scripte wären nicht so abhängig vom eigenen System.



    OK, etwas OT hier, aber evtl. taugt es ja auch gleichzeitig zur Anregung von Funktionen für vdr-scripting.


    Zitat

    Originally posted by Urig


    Außerdem pollt OSDServer nicht, dafür gibt es ein Event-System.


    Habe ich mich wohl unglücklich ausgedrückt. Ich meinte, das Script kann den OSDServer nur fragen und dann reagieren. Der OSDServer selber kann nicht auf Ereignisse reagieren indem es dann entsprechend Funktionem vom Script aufruft.
    Wobei das für die OSD Sache ja auch vollkommen OK ist. Nur weitere Funktionen (z.B. beim Housekeeping irgendwas machen, beim VDR Start irgendwas machen) liessen sich auf diese Weise wohl nicht realisieren.


    Hier sind dann wohl die Unterschiede zwischen beiden Pluginis zu sehen.


    Zitat

    Originally posted by Urig
    Ein wesentlicher Unterschied: OSDServer-Skripte sind extern: Sie werden per commands.conf oder ähnlich gestartet, und können (bisher) keinen Mainmenu-Eintrag haben.


    Mit dem Menueorg-Plugin (Oder dem Setup-Plugin, eines von beiden hat wohl jeder um Submenues/Sortierte Menues zu haben) lassen sich Haupmenüeinträge auch Sripten zuordnen.
    Ferner kann man die Fernbedienung auch so konfigurieren das auf Tastendruck ein Script gestartet wird (anstelle eines Plugins).


    Also kann man mit dem OSDServer durchaus Scripte schreiben die sich später in der Benutzung nicht von normalen Plugins unterscheiden.
    Ich sah hier bis jetzt jedenfalls kein Problem was einem daran hindert einfache Plugins (irgendwas per OSD machen und fertig) in Scriptsprachen zu schreiben.


    cu

  • Code
    etc/vdr/plugins/scripting/lib/vdr/pluginmanager.rb:42: [BUG] Segmentation fault
    ruby 1.8.6 (2007-06-07) [i486-linux]


    Was nun?
    Ist nun eventuell Ruby zu alt?


    Gruß
    Ranga

    - yavdr 0.6.1 -


    . . : : ASUS AT3IONT-I , 2 GB RAM : : Mystique Satix Dual S2 ::..
    ..:: Silverstone ML02B-MXR :: Samsung 1,5TB Eco Green : : Logitech Harmony 1100::..

  • Zitat

    Einer der Gründe dafür ist, dass C/C++ im Vergleich zu C#, Ruby, Python oder <HIER deine Lieblingssprache einfügen> einfach nicht so viel Spaß macht

    Also wenn ich mir anschaue wie "toll" die tvmovie perl-Skripte laufen (Speicherverbrauch anscheinend ohne Ende) empfinde ich so eine Idee natürlich "wunderbar". Auch der Gedanke, das ich für Plugins bald irgendeine <HIER deine nicht installierte Sprache einfügen> Software installieren muss empfinde ich als äußerst befremdlich.


    Nicht ohne Grund wurde für tvmovie ein Plugin geschrieben.


    Gruß

    Joe_D

  • Urig: Danke! Ein bischen Konkurrenz hat noch nie geschadet :)


    Ist ja nicht so, dass ich grundsätzlich was gegen C++ hätte, aber da ich in den letzten Jahren beruflich fast auschließlich nur noch in C# programmiere, bin ich wohl etwas vewöhnt. Generics vs. Templates, Lambdas vs. Method-Pointers, Mono/MS.Net vs Boost/STL - da kann man schon ein bischen die Lust an C++ verlieren. Aber ohne C/C++ gäbs auch kein Ruby oder Python - hat halt alles irgendwo seine Daseinsberechtigung - für jeden Job das passende Tool :)


    Ranga: In deiner PN fehlt leider der Anhang.

  • Zitat

    Originally posted by Joe_D

    Also wenn ich mir anschaue wie "toll" die tvmovie perl-Skripte laufen (Speicherverbrauch anscheinend ohne Ende) empfinde ich so eine Idee natürlich "wunderbar".


    Das liegt aber nicht an <Scriptsprache> sondern an der konkreten Umsetzung. Man kann mit Scripten auch XML Parsen ohne das man ne 2GB Swap Datei anlegt ;)


    cu

  • Hört sich echt interessant an. Ich bin zwar eher auf Java zu Hause, aber das wird ja anscheinend auch von swig unterstützt und soweit ich das richtig verstanden habe aus ein und dem selbem interface generiert.
    Ich musste ja direkt daran denken, dass man eventuell den Vodcatcher Helper direkt in das Vodcatcher-Plugin integrieren könnte.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!