Restfulapi-Plugin

  • Saman: Forke Dir doch einfach das restfulapi-Plugin auf github und entwickele da weiter, generiere daraus dann Pull-Requests / Patches für das Haupt-Repo.


    https://github.com/Saman-VDR/vdr-plugin-restfulapi

  • Moin,


    und noch ein 'feature request', das ich gerne ins git übernehmen würde.


    Der Patch ergänzt 'events' um drei neue Optionen:

    • chevents -> EPG Einträge pro Kanal
    • chfrom -> EPG ab Kanalnummer
    • chto -> EPG bis Kanalnummer


  • Ich konnte die Probleme mit der json-Ausgabe auf die Version 2.1.1 von cxxtools zurückführen. Falls da noch jemand Probleme hat:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Done.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,


    zu den 'OPTIONS' habe ich noch was gefunden:


    Zitat

    Unlike simple requests (discussed above), "preflighted" requests first send an HTTP OPTIONS request header to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. In particular, a request is preflighted if: ...


    https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-US&redirectslug=HTTP_access_control

  • Moin,


    als Antwort auf https://bugs.yavdr.com/issues/840
    und weil ich es auch brauche würde ich das gerne übernehmen:


  • info.xml zeigt beim streamen oder scannen den Kanal des zweiten Tuners an.
    Das hilft bei mir:


  • Danke! Am besten auch an einen Bug hängen, wenn ich einen Thread im Portal gelesen habe, hab ich's meistens auch schon wieder vergessen... :)


    Lars.

  • Ich konnte die Probleme mit der json-Ausgabe auf die Version 2.1.1 von cxxtools zurückführen. Falls da noch jemand Probleme hat:


    Danke für den Patch. Der VDR verabschiedete sich auch immer bei der Anzeige von Events als json. Nun scheint es zu gehen.

    HD-VDR:
    HW: ZOTAC D2550-ITX | Mystique SaTiX-S2 Sky Xpress DUAL
    SW: Debian Stretch | vdr-2.3.8

  • Moin,


    anbei ein Patch gegen https://github.com/Saman-VDR/vdr-plugin-restfulapi
    Der Patch ergänzt info um ein paar Ausgaben und das Plugin um einen weiteren Service: audio


    Edit: Patch entfernt, Änderung ist im Git.


    audio.xml?volume=180&track=33&mute=0&channel=0
    audio.xml?volume=180 // 180 absolute
    audio.xml?volume=020 // +20
    audio.xml?volume=-20 // -20


    audio.xml


    info.xml

    Einmal editiert, zuletzt von Saman ()

  • Moin,


    da hier niemand aufgeschrien hat, habe ich die Ergänzungen ins Git übernommen.
    Der Patch muss also nicht mehr angewendet werden.


    Gruß S.

  • Moin!


    In deinem git darfst du tun, was du möchtest... :)
    Hatte noch keine Gelegenheit, den Patch einem Review zu unterziehen, habe es aber noch vor.


    Lars.

  • Ist schon klar, aber ich möchte es ja so einbauen, das es auch übernommen wird.
    Vorschläge sind also immer willkommen.



    Mein Entwurf zum Testen des Volume-Reglers mit Safari und Chrome sieht so aus:

    Einmal editiert, zuletzt von Saman () aus folgendem Grund: GET wurde zu POST

  • Code
    audio.xml?volume=020 // +20
    audio.xml?volume=-20 // -20


    Ich vermute das hat sich aus dem sonst umständlichen Escapen des "+" ergeben - evtl. wäre ein audio.xml?volumeup=20 und audio.xml?volumedown=20 als sprechende Alternativen einfacher, dann könnte man in seinem Konstruktor für die URL auch mit Integern statt Strings für die Werte arbeiten.


    Dann habe ich noch eine Frage zur Methode - wenn ich das richtig interpretiere wird die Lautstärke im Patch per GET gesetzt, was ja ein bisschen einer "sicheren" Methode widerspricht (http://en.wikipedia.org/wiki/H…fer_Protocol#Safe_methods) - das gleiche hat sich bei Play auch schon eingeschlichen:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich vermute das hat sich aus dem sonst umständlichen Escapen des "+" ergeben...


    Richtig vermutet ;)

    Zitat

    ... - evtl. wäre ein audio.xml?volumeup=20 und audio.xml?volumedown=20 als sprechende Alternativen einfacher, dann könnte man in seinem Konstruktor für die URL auch mit Integern statt Strings für die Werte arbeiten.


    volumeup und -down kann ich gerne einbauen aber als Integer nehme ich es jetzt schon entgegen ( int level = q.getOptionAsInt("volume"); )


    Dann habe ich noch eine Frage zur Methode - wenn ich das richtig interpretiere wird die Lautstärke im Patch per GET gesetzt, was ja ein bisschen einer "sicheren" Methode widerspricht (http://en.wikipedia.org/wiki/Hypertext_T…ol#Safe_methods) - das gleiche hat sich bei Play auch schon eingeschlichen:...


    Da hast du recht. Kann ich gerne ändern.
    Wichtig ist mir nur, das beim setzen der Lautstärke das Ergebnis auch gleich zurück gegeben wird.
    Das habe ich jetzt eben mit POST probiert und es funktioniert.


    Play - Was haltet ihr davon?
    POST http://<ip>:<port>/recordings/playstart/<number>
    POST http://<ip>:<port>/recordings/play/<number>


    oder
    POST http://<ip>:<port>/recordings/rewind/<number>
    rewind wird ihmo im VDR verwendet, ich finde das aber irgendwie missverständlich

  • Habe den AudioResponder im Git angepasst.
    Was meint ihr dazu?


  • rewind wird ihmo im VDR verwendet, ich finde das aber irgendwie missverständlich


    Ja, verständlich. Aber ich würde da von der Namenswahl so dicht wie möglich am vdr bleiben, dann finden sich die Leute besser zurecht, die den vdr schon kennen.
    Sonst baut man sich eine eigene API zurecht, die man auch erst wieder lernen muss... :)


    Lars.

Jetzt mitmachen!

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