Restfulapi-Plugin

  • Moin,
    wird an dem Plugin noch gearbeitet (ausser Makefile anpassen)?
    Bei den Suchtimern bin ich da doch auf einige Unzulänglichkeiten gestoßen...


    S.


    Edit: Die in diesem Thema vorgeschlagenen Änderungen gibt es jetzt auch im Git:
    https://github.com/Saman-VDR/vdr-plugin-restfulapi

    The post was edited 1 time, last by Saman ().

  • Es ist zumindest nicht orphaned denke ich - um was gehts denn ? Wenn du es nicht hier erörtern willst kannst du auch entsprechende Bugs @ bugs.yavdr.com (das Plugin hat ein Projekt dort) aufmachen :)

  • Moin!


    Ich nehme Patches entgegen (hab auch noch welche liegen, die ich noch einpflegen möchte).
    Einfach im yaVDR-Bugtracker hinterlegen und mir zuweisen.


    Lars.

  • Versteht mich nicht falsch, ich finde das Plugin großartig und mache in meinem WebApp regen Gebrauch davon.


    Ein Teil der Probleme sind ja in den Sourcen schon aufgezeigt.


    Code
    1. if (useAsSearchtimer == 2 /*user defined*/) {
    2. //read time_t m_useAsSearchTimerFrom
    3. //read time_t m_useAsSearchTimerTil
    4. //to be implemented in the parser and in the webservice output // add methods to SearchTimer-class
    5. return "use_as_searchtimer mode user defined not supported in restfulapi (at least currently)";
    6. }


    Code
    1. //int m_blacklistmode
    2. //std::vecotr< std::string > m_blacklist_IDs;
    3. //m_blacklistmode: 0=no, 1=Selection, 2=all
    4. //to be implemented, requires array-support in QueryHandler for xml/html and json -> html param-parser has to be impelemented???
    5. //and blacklist ids should be added to the webservice output
    6. int blacklistmode = q.getBodyAsInt("blackliste_mode");
    7. if (blacklistmode > 0) return "blacklist currently not implemented";


    Dann funktioniert das Löschen von Timern bei mir mit keinem Browser richtig:


    mein workaround dafür:

    Code
    1. // php curl workaround
    2. EpgSearch.delTimer = function(timerId)
    3. {
    4. makeRequest('remotes.php', '?delete&key=searchtimers/'+timerId);
    5. setTimeout("getSearchTimer();", 1000);
    6. //Display.showInfobar("Such-Timer wurde gel&ouml;scht", 3000);
    7. }


    über einen kleinen Umweg geht das dann an diese Funktion


    Firefox hat aber auch generell ein Problem mit dem DELETE. Das liegt nicht umbedingt am Plugin, mit Chrome und Safari funktioniert es ja.


    Korrigiert mich, wenn ich falsch liege...

    The post was edited 1 time, last by Saman ().

  • Die Begrenzung der Titlelänge beim anlegen von Timern ist auch doof ;)

  • Moin!


    Viel Zeit zum Einarbeiten und Weiterentwickeln von restfulapi habe ich momentan nicht, aber wenn du gute Patchtes lieferst, werde ich die sicherlich übernehmen können.
    Vielleicht meldet sich aelo ja auch irgendwann wieder...


    Lars.

  • Eigendlich hatte ich ja gehofft... und ich debugge dann ein bisschen.


    Habe mir aber jetzt die source installiert und schaue ob ich was hinbekomme, learning by doing.

  • Moin,


    nach dem Patch funktioniert bei mir das löschen der Suchtimer mit der Funktion von oben.
    Auch das löschen von Timern mit Firefox geht damit.


    Die Probleme werden anscheinend dadurch verursacht, dass die Abfrage von 'request.method()' ein zusätzliches 'OPTIONS' zurück gibt.
    Warum das passiert erschliesst sich mir nicht.



    P.S.: Wegen dem 'OPTIONS' sollte eventuell nach der eigendlichen Ursache ( cxxtools? ) gesucht werden.
    Die 'reply.addHeader' sollten IMHO aufjedenfall raus, da die ja schon beim 'QueryHandler::addHeader(reply);' gesetzt werden.

    The post was edited 1 time, last by Saman ().

  • Moin!


    Erstellst du mir bitte unter https://bugs.yavdr.com/projects/yavdr/issues ein Ticket mit Link zum Post?
    Dann vergesse ich das nicht, wenn ich wieder Zeit für den Bugtracker hab.


    Danke!


    Lars.

  • Moin,


    anbei ein Patch, der:

    • das Problem mit 'request.method() == "OPTIONS"' für Timer, Suchtimer und Aufnahmen umschifft.
    • das mehrfache setzen der Header in searchtimers.cpp behebt
    • die maximale Titellänge der Timer von 40 auf 99 Zeichen erhöht
    • ein paar kleinere Fehler in osd.cpp behebt
    • WebApp support im Header von osd.html einfügt


    S.

    Files

  • Moin,


    und noch ein 'feature request'.
    Der Patch ergänzt die Rückgabe von 'events' um den Kanalnamen:

    Files

  • Hatte ich auch mal drüber nachgedacht, ist aber eigentlich redundant.


    Ist Redundanz bei sowas gewünscht? Ich kenne mich mit dem "was ist hier üblich" nicht aus.



    BTW: Wenn Redundanz dann richtig, d.h. der ShortChannelName sollte dann auch noch mit rein.



    cu

  • Für mich gibt es da einfach einen praktischen Fall in meinem WebApp.

    Quote

    Leider gibt restfulapi-plugin im EPG die Kanalnamen nicht mit. Diese bekommt das App erst nach einem Besuch bei den Kanälen. Oder aus settings/channelnames.js.
    Wer also beim EPG SenderID statt Namen angezeigt bekommt, muss channelnames.js im Setup erstellen.
    Dazu einfach oben auf den Button 'Erst. Liste' drücken.


    Da muss ich mir die Kanalnamen extra in ein separates Array laden..., um bei der Darstellung des EPG nicht nur die SenderID anzuzeigen.


    Quote

    BTW: Wenn Redundanz dann richtig, d.h. der ShortChannelName sollte dann auch noch mit rein.


    In channels.cpp gibt es auch kein ShortChannelName. :lehrer1

  • In channels.cpp gibt es auch kein ShortChannelName. :lehrer1


    Jup, da fehlt er auch ;)


    Da muss ich mir die Kanalnamen extra in ein separates Array laden..., um bei der Darstellung des EPG nicht nur die SenderID anzuzeigen.


    Klar, ich mache es bei mir aktuell auch so das ich zu jedem EPG Eintrag nochmal den Channeleintrag hole um den Namen mappen zu können. Vom Aufwand her ist das ja überschaubar.


    Die Frage ist was bei restful/json so allgm. üblich ist. Redundanz ist hier ja ganz praktisch, scheint nur etwas unsauber weil eigentlich technisch überflüssig.
    Aber prinzipiell finde ich es aber auch gut den gleich mitzubekommen (Spart bei mir 10 Zeilen Code und nen Extra Request).


    cu

  • Moin,


    und noch ein 'feature request'.
    Der Patch ergänzt 'recordings/play' um die Möglichkeit, eine Aufnahme vom Anfang abzuspielen:


    Files

  • Moin!


    Hui, wird ja richtig voll hier... Ich denke, ich verliere den Überblick... :)


    Da ich vermutlich erst am Mittwoch (wenn überhaupt) dazu komme, das einfach einzupflegen, würde ich mich über entsprechende git-pull-requests freuen (einfach bei GitHub forken oder zur Not im lokalen git per "format-patch" und dann per E-Mail an mich => dvb@flensrocker.de)
    Dazu dann passende Commit-Messages usw., damit es "rund" wird. :)


    Toll, dass das Plugin noch Anhänger hat!


    Lars.

  • Was mir noch aufgefallen ist: wenn man per LC_ALL die Sprache z.B. auf de_DE.UTF-8 setzt, crasht das Plugin beim Anzeigen der Aufnahmen http://<IP des VDR>:<Port>/recordings.json
    http://paste.ubuntu.com/5564513/


    Wenn man nur VDR_LANG=de_DE.UTF-8 (und ggf. VDR_CHARSET_OVERRIDE) setzt, klappt es (wie in yaVDR) ohne Probleme.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,

    Was mir noch aufgefallen ist: wenn man per LC_ALL die Sprache z.B. auf de_DE.UTF-8 setzt, crasht das Plugin beim Anzeigen der Aufnahmen http://<IP des VDR>:<Port>/recordings.json


    habe bei mir in /etc/evironment mal LC_ALL="de_DE.UTF-8" eingefügt und neugestartet. locale gibt danach LC_ALL="de_DE.UTF-8" aus.
    Plugin stürzt beim Abrufen von /recordings.json aber nicht ab.

  • Ah entschuldige, da bin ich durcheinander gekommen - da hat eine Locale auf dem Bastel-System gefehlt.


    Edit: das Problem tritt hier doch noch auf, wenn Aufnahmen mit Umlauten eingebunden sind - mal sehen ob ich das noch weiter eingrenzen kann...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().