Hallo
Ich wuerde auch gerne Tasten via svdrpsend oder dbus2vdr senden. Das ist allerdings limitiert auf 1 Aktion pro Sekunde. Hat jemand ne Idee wie man dem Beine machen koennte ?
Hallo
Ich wuerde auch gerne Tasten via svdrpsend oder dbus2vdr senden. Das ist allerdings limitiert auf 1 Aktion pro Sekunde. Hat jemand ne Idee wie man dem Beine machen koennte ?
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.
svdrpsend.pl und vdr-dbus-send.sh senden bei mir beide so ca einen Befehl pro Sekunde raus, das laesst sich einfach mittels
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
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
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.
#!/usr/bin/env python
# coding=utf-8
import dbus
bus = dbus.SystemBus()
HitKey = bus.get_object('de.tvdr.vdr', '/Remote')
a = 0
while a < 10 :
a += 1
HitKey.HitKey("right",dbus_interface = 'de.tvdr.vdr.remote')
Alles anzeigen
Seltsam, ich dachte eigentlich das das schneller ist?
cu
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.
Zitatdbus2vdr 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
ZitatProbier 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
#!/usr/bin/env python
# coding=utf-8
import os
a = 0
while a < 10 :
a += 1
os.system("/usr/bin/dbus-send --system --type=method_call --dest=de.tvdr.vdr /Remote de.tvdr.vdr.remote.HitKey string:'right' &")
Alles anzeigen
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
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:
#!/bin/python
# -*- coding:"utf-8" -*-
import sys
import traceback
import gobject
import dbus
import dbus.mainloop.glib
# Callbacks for asynchronous calls
def handle_reply(r,*args):
print "replied", str(r)
return True
def handle_error(e):
print "dbus-handler raised an exception! That's not meant to happen..."
print "\t", str(e)
def make_calls(remote,key):
remote.send_key(key)
return True
class dbusVDRremote():
def __init__(self):
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
try:
proxy_obj = bus.get_object("de.tvdr.vdr", "/Remote")
self.remote = dbus.Interface(proxy_obj, "de.tvdr.vdr.remote")
except dbus.DBusException:
traceback.print_exc()
print usage
sys.exit(1)
def send_key(self, key):
self.remote.HitKey(str(key),reply_handler=handle_reply,
error_handler=handle_error)
return True
def main():
remote = dbusVDRremote()
key = "DOWN"
gobject.timeout_add(150, make_calls, remote, key) # Sends a "HitKey DOWN" every 150ms - replace by another gobject-event to do something useful... (have a look at lircd2uinput if you want to know how to read a lircd-socket using event-polling together with gobject https://github.com/yavdr/yavdr-utils/blob/master/lircd2uinput/lircd2uinput ;)
loop = gobject.MainLoop(is_running=True)
while loop.is_running():
try:
loop.run()
except:
print "Unexpected error:", sys.exc_info()[0]
raise
mainloop.quit()
if __name__ == '__main__':
main()
Alles anzeigen
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
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!