svdrpsend oder dbus2vdr beschleunigen

  • Das ist allerdings limitiert auf 1 Aktion pro Sekunde. Hat jemand ne Idee wie man dem Beine machen koennte ?


    Wieso "Beine machen" und "beschleunigen" wenn du es auf max. 1 Aktion pro Sekunde begrenzen willst? Was hast du vor?


    cu

  • helau möchte es nicht auf eine Sekunde begrenzt haben, sondern er sagt das es das ist und er es gerne schneller hätte. Woher die Limitierung kommt/kommen soll weiss ich allerdings nicht. Ich vermute dbus2vdr benutzt das selbe wie svdrp, restfulapi machts dann wohl auch so ? Kommt das von cRemote::Put ? Kann man vielleicht mehr als eine Taste pro Call übergeben (wenn nicht von Put kommt) und woher kommt die Einsicht das es nur eine Taste pro Sekunde gibt ?

  • Das ist allerdings limitiert auf 1 Aktion pro Sekunde. Hat jemand ne Idee wie man dem Beine machen koennte ?


    Wie sendest du denn Tasten an das dbus-Plugin? Evtl. macht es Sinn eine Variante zu wählen, bei der nicht pro Aktion eine Verbindung zu dem dbus2vdr-plugin erzeugt wird (wie bei dbus-send bzw. dem Wrapper vdr-dbus-send.sh), sondern das Verbindungsobjekt gehalten wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • svdrpsend.pl und vdr-dbus-send.sh senden bei mir beide so ca einen Befehl pro Sekunde raus, das laesst sich einfach mittels

    Code
    1. for i in $(seq 1 10) ; do svdrpsend chan ; done


    testen. Egal welche Aktion man ausfuehrt dauert das bei mir 1 Sekunde im Schnitt. Um z.B. ein input device zu nutzen ist dies zu langsam.
    Ich weiss dafuer gibts das remote Plugin, aber ich habe nen eigenen eventmapper, welcher auch Makros ausfuehren kann, daher ist das remote plugin dafuer ungeeignet.
    Variante B) waere Lirc commands zu senden, das sollte schneller moeglich sein.

  • Moin!


    Ich könnte mir vorstellen, "HitKey" von dbus2vdr zu erweitern bzw. eine neue Methode "HitKeys" einzubauen, die ein Array von Tastendrücken entgegennimmt.
    Der Verbindungsaufbau (egal ob Socket oder DBus) dauert leider seine Zeit, deshalb könntest du auch überlegen, ob du statt eines Shell-Scripts vielleicht auf Python oder eine andere Sprache umstellst, wo du einmal eine Verbindung aufbaust und diese dann immer wieder benutzt.
    DBus soll mit Python eigentlich recht einfach zu benutzen sein, hab's aber noch nie richtig gemacht, da ich kein Python kann.


    dbus2vdr benutzt intern "cRemote:: Put", siehe https://github.com/flensrocker…blob/master/remote.c#L175
    Keine Ahnung, wie "schnell" das geht oder nicht.


    Lars.

  • Probier doch mal das restfulapi, vielleicht ist das ja schneller.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Den reinen Verbindungsaufbau kann man für viele Tastendrücke "wegoptimieren". Ich habe mir z.B. ein Perl-Modul für SVDRP gebaut, welches die Verbindung über die gesamte Laufzeit meines Perl-Programms geöffnet lässt und anfallende Aufrufe über die offene Verbindung absetzt. Selbstverständlich kann man sowas nur für Programme machen, die nur wenige Sekunden Laufzeit haben, denn sonst wäre die SVDRP-Verbindung dauerhaft durch dieses eine Programm belegt.

  • OT:
    dbus Aufruf mit Python:
    https://github.com/yavdr/vdr-a…master/avahi-mounter#L213
    Relevant ist 215 - 217 und import dbus



    Angenommen es ist ein Eventgerät/uinput daemon, dann denke ich bei uns würde sowas bei uns zu eventlircd geschickt werden, der das dann normal per Lirc an den VDR schickt.

  • Also das

    Code
    1. for i in $(seq 1 10) ; do /usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Remote de.tvdr.vdr.remote.HitKey string:'right'; done


    läuft bei mir mit gefühlten 15 Anschlägen pro Sekunde. Getestet in nen Edit Feld (Da rast der Cursor nach Rechts).


    Ich nutze dbus2vdr auch um Fernbedienungkommandos zum VDR zu bringen (über lircrc und irexec). Und das läuft eigentlich Verzögerungsfrei und ohne Probleme.


    BTW: Python ist echt träge, das braucht wirklich 1 Sekunde pro Taste.


    Seltsam, ich dachte eigentlich das das schneller ist?


    cu

  • Also das

    Code
    1. for i in $(seq 1 10) ; do /usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Remote de.tvdr.vdr.remote.HitKey string:'right'; done


    läuft bei mir mit gefühlten 15 Anschlägen pro Sekunde. Getestet in nen Edit Feld (Da rast der Cursor nach Rechts).


    Das koennte der entscheidende Hinweis sein :)
    Bei Dir fehlt der Parameter --print-reply , da werde ich heute abend mal testen ob das den Ausschlag macht.


    Zitat

    dbus2vdr benutzt intern "cRemote:: Put", siehe https://github.com/flensrocker/vdr-plugi…r/remote.c#L175
    Keine Ahnung, wie "schnell" das geht oder nicht.


    Das ist sicher schnell genug


    Zitat

    Probier doch mal das restfulapi, vielleicht ist das ja schneller.


    Werde ich auch heute abend mal machen ...

  • Bei Dir fehlt der Parameter --print-reply , da werde ich heute abend mal testen ob das den Ausschlag macht.


    Stimmt, jetzt wo du es sagst... Mal getestet, mit --print-reply komme ich hier auch auf einen Anschlag pro Sekunde. Ich hatte den nicht bewusst weggelassen, war eher Zufall das ich das in diesem Fall immer ohne nutzte (hier brauchts ja keinen Reply also setzte ich den Parameter erst gar nicht).


    Das könnte auch ne Erklärung sein warum die Pythonvariante so träge ist. Vermutlich wartet die Python Implementierung immer auf nen Reply.


    cu

  • Moin!


    Das "--print-reply" wartet auf den Rückgabewert des Aufrufs, wenn du den nicht brauchst, kannst du einfach die Aufruf absetzen und gut ist. Ist dann sowas ähnliches wie ein DBus-Signal (fire and forget).
    Das wird das sicherlich etwas beschleunigen.


    "HitKeys" einzubauen ist auch nicht so schlimm, werde ich demnächst mal tun. dbus2vdr ist sowieso dazu gedacht, auf Zuruf um die nötigen Funktionen erweitert zu werden. :)
    Ich freu mich über jeden neuen Nutzer...


    Lars.

  • Moin!


    Was ich sonst noch zu Python/DBus gefunden habe:
    http://dbus.freedesktop.org/do…asynchronous-method-calls


    Und hier ganz am Ende schreibt er irgendwas von "ignore_reply", kann ja mal jemand mit Ahnung ausprobieren... :)
    http://smcv.pseudorandom.co.uk/2008/11/nonblocking/


    Lars.

  • Hier ist die non Blocking Python Lösung ;)


    Ernsthaft, da brauchts für die Python Lösung anscheinend Threading und irgendwie wirds dann komplizierter (jedenfalls zu komplizierter für nen kleines Tastensendscript). Aber wenn hier jemand ne saubere Python Lösung kennt und Posten mag ... ;) Ich würde mich freuen das mal zu sehen.


    cu


  • Clown gefrühstückt? :)


    Nur etwas frustriert vom Versuch es richtig zu machen ;) Irgendwie wollte die dbus Loop nicht so in nen extra Thread so wie ich das wollte.


    cu

  • Moin!


    dbus2vdr 0.0.4c kann nun mehrere Tasten in einem Rutsch in den vdr jagen.
    Einfach mehrere angeben:

    Code
    1. vdr-dbus-send /Remote remote.HitKey string:'Menu' string:'Down' string:'Down' string:'Ok' ...


    Ich hoffe, das ist dann schnell genug, selbst mit der Rückmeldung... :)


    Lars.

  • So, nach einer kleinen experimentellen Phase (ist ganz einfach, wenn man mal verstanden hat, was man tun muss ;)) kann ich eine Lösung für nicht-blockierende Aufrufe per dbus in Python präsentieren:


    Das Beispiel-Skript drückt alle 150ms die Nach-unten Taste - hier könnte man aber auch eine Reaktion auf eine Änderung an einem Socket, einer Datei oder anderen Events mit Callback, die gobject bietet einhängen. Ein Beispiel für einen Lirc-Socket mit gobject.io_add_watch findet man hier: https://github.com/yavdr/yavdr…lircd2uinput/lircd2uinput

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dieser Beitrag wurde bereits 6 Mal editiert, zuletzt von seahawk1986 ()

  • Moin!


    dbus2vdr 0.0.8 sollte nun flotter reagieren, so langsam verstehe ich, was dbus von mir will...
    Eine Implementation des dbus-main-loops ist keine einfache Sache, vor allen Dingen, weil es so gut wie gar nicht dokumentiert ist.


    Lars.