Suche Plugin, um AV-Receiver über Netzwerk zu steuern

hi,

ich weiß nicht was du dir vorstellst aber der av receiver hat nur begrenze "schnittstellen" über die er gesteuert werden kann, wenn er keine direkte netzwerkschnittstelle hat läuft es im wesentlichen auf ir hinaus
theoretisch kommen von CEC über HDMI (http://de.wikipedia.org/wiki/Consumer_Electronics_Control) oder bluetooth in betracht aber das müsste der receiver schon aktiv unterstützen und fertige vdr plugins gibts da glaube ich auch nicht, der weg den yavdr geht ist da glaube ich evrntlircd, wenn es da rein passt könnte es sich das immerhin einbinden lassen

hi,

würde ich auch so sehen das das Uactivity-Plugin das richtige dafür ist
wenn du dir ein passendes script basteln kannst das die passende aktion an den receiver sendet sollte man das damit in vdr zuordnen können
ansonsten frag doch mal "Keine_Ahnung" hier im vdrportal

Uactivity ist im Prinzip für sowas gedacht.

Allerdings ist cStatus (und damit Reaktionen auf Lautsärkeänderungen) noch nicht drin (ist aber geplant). Wobei ich nicht wiess ob man an den Mute Status kommt, cStatus scheint nur die Lautstärke zu liefern. Aber ich schaue mal.

cu

Moin,

Demnächst wird dbus2vdr die cStatus-Schnittstelle unterstützen und Mute und Lautstärke kann man auch abfragen.
Die cStatus-Aufrufe werden als dbus-Signale nach außen gegeben, damit kann dann ein externer Daemon reagieren und man ist etwas unabhängiger.

Dauert aber noch ein paar Tage, da ich mit dem Port nach GDBus noch nicht ganz fertig bin.

Lars

Zitat von mini73

Die cStatus-Aufrufe werden als dbus-Signale nach außen gegeben, damit kann dann ein externer Daemon reagieren und man ist etwas unabhängiger.

Prima, ich bin schon gespannt was man damit anstellen kann

Zitat von mini73

Demnächst wird dbus2vdr die cStatus-Schnittstelle unterstützen und Mute und Lautstärke kann man auch abfragen.
Die cStatus-Aufrufe werden als dbus-Signale nach außen gegeben, damit kann dann ein externer Daemon reagieren und man ist etwas unabhängiger.

Inklusive der Graphtft-Erweiterungen? Ein externes OSD über dbus getriggert, cool, sorry, nur laut gedacht.

Gerald

graphtftng ist dann auch jetzt schon multiclient fähig und wenn ich Jörg richtig verstanden habe ist dann auch mit sowas wie eine Ipad app zu rechnen...

wenn man das Ganze dann mit dbus füttern kann und unabhängig vom OSD ist: umso besser!

Christian

Zitat von CKone

wenn ich Jörg richtig verstanden habe ist dann auch mit sowas wie eine Ipad app zu rechnen...

Das würde mir eher nix nützen.

Gerald

Moin,

Zurück zum Thema.

Wenn du die Steuerbefehle für deinen Receiver zumindest in Shellscripte oder ein anderes Programm umsetzen kannst, findet sich schon eine Lösung, wie man die passend aufrufen kann.
Hast du da mal ein zwei Beispiele, was möglich ist?

Lars

Zitat von vdrstarter

Keine_Ahnung:
Was hat es mit dem cStatus auf sich? Goggle hat dazu nichts gewußt und die Sourcen wollte ich nicht ganz durchlesen...

Der VDR bietet eine Möglichkeit (halt das besagte cStatus) das sich Plugins über solche Sachen informieren lasssen können.

Ich baue das in uactivity ein, dann wird bei jeder Volumeänderung (Nachrichten und Umschalten folgen dann auch) ein uactivity status Script aufgerufen. Und dieses könntest du dir dann so einstellen wie du möchtest. Ist im Prinzip simpel.

Aber wenn du uactivity nutzen willst brauchst du noch einige Tage Gedult, ich habe gestern mein neues (und auch mein erstes) Smartfone bekommen und bin jetzt erstmal abgelenkt

cu

PS: Nen Daemon mit dbus2vdr der am dbus lauscht und die Telenetverbindung offen hält wäre natürlich eleganter als Scriptaufrufe und "cat volup.txt | telnet ip 50000". Aber kleine uactivity Scripte sind einfacher für den User als nen Daemon zu scheiben. Such dir aus welchen Weg du gehen willst.

Zitat von vdrstarter

Keine_Ahnung:
Was hat es mit dem cStatus auf sich? Goggle hat dazu nichts gewußt und die Sourcen wollte ich nicht ganz durchlesen...

Das wäre ja auch ziemlich albern. Ein

grep cStatus *

würde einem das ja ersparen.

Gerald

Moin!

Zitat von Keine_Ahnung

PS: Nen Daemon mit dbus2vdr der am dbus lauscht und die Telenetverbindung offen hält wäre natürlich eleganter als Scriptaufrufe und "cat volup.txt | telnet ip 50000". Aber kleine uactivity Scripte sind einfacher für den User als nen Daemon zu scheiben. Such dir aus welchen Weg du gehen willst.

Ja, da hast du Recht, deshalb starten wir das am besten auch mit kleinen Scripts. Wenn es dann einen Programmierbegeisterten gibt, der das gut findet und weiter ausbauen möchte, können wir immer noch den nächsten Schritt gehen.
In Python ist das erstaunlich schnell zusammen gezimmert, um auf dbus-Signale zu reagieren. Und mit Qt ist's auch nicht schwer...

Ich will aber deinem uactivity nicht im Weg stehen, es ist immer gut, mehrere Lösungswege zu haben. Und ich brauche ja auch noch ein paar Tage...

vdrstarter:
zu cStatus:
Da gibt es u.a. eine Funktion, die jedes mal aufgerufen wird, wenn die Lautstärke sich ändert (siehe status.h in den vdr-Sourcen):

virtual void SetVolume(int Volume, bool Absolute) {}
               // The volume has been set to the given value, either
               // absolutely or relative to the current volume.

Das wird dann demnächst per dbus2vdr nach außen getragen, so dass externe Programme darauf reagieren können.
Und wenn das auch in uactivity eingebaut wurde, wird man jede Lautstärkenänderung an ein Script weiterreichen können.

Ich bin mal gespannt, ob das performant genug ist, wenn jedes mal ein Script gestartet wird, das dann eine Netzverbindung aufbaut, um den Befehl abzuschicken. Ist schon etwas Overhead für Tastendrücke, die prinzipiell schnell aufeinander folgen können.

Oder du steigst in die Plugin-Programmierung ein, und baust ein eigenes Plugin.
Kann der Receiver denn mit einer Verbindung umgehen, die offen gehalten wird? Kann man dann mehrere Befehle nacheinander senden?
Oder hast du einen Link auf Doku?

Lars.

Zitat von mini73

Ich will aber deinem uactivity nicht im Weg stehen, es ist immer gut, mehrere Lösungswege zu haben. Und ich brauche ja auch noch ein paar Tage...

dbus2vdr und uactivity haben ja auch sehr unterschiedliche Einsatzbereiche.

Fürs TV an/-ausschalten oder um das http://www.vdr-wiki.de/wiki/index.php/Statusleds-plugin zu ersetzen ist uactivity IMHO der korrekte Ansatz.

Um einen Display Daemon zu schreiben und für die AV Receiver Lautstärkeregelung ist ein Daemon am dbus IMHO der richtig Weg.

Wobei man natürlich auch zusätzlich einen uactivity Daemon schreiben kann (habe ich mir so als ToDo im Hinterkopf gesetzt) der auf dem dbus lauscht und die uactivity Scripte aufruft (dann spart man ein Plugin wenn man eh dbus2vdr am laufen hat). Mir gehts bei uactivity auch eher ums Scriptgerüst (halt das zu normieren (damit Scripte von Usern austauschbar sind) und Beispiele zu liefern) als um das Plugin.

Zitat von mini73

Ich bin mal gespannt, ob das performant genug ist, wenn jedes mal ein Script gestartet wird, das dann eine Netzverbindung aufbaut, um den Befehl abzuschicken. Ist schon etwas Overhead für Tastendrücke, die prinzipiell schnell aufeinander folgen können.

Jup, da werde ich dann mal live spielen. Entweder gibts im Plugin nen Filter (max. alle 500ms ein Aufruf) oder im Script.

Zitat von mini73

Oder du steigst in die Plugin-Programmierung ein, und baust ein eigenes Plugin.

Wobei dbus2vdr, restfulapi und uactivity ja schon Möglichkeiten bieten mal langsam von den 500 Kleinkramplugins wegzukommen IMHO besser sowas zu nutzen als ein weiteres zu schaffen.

cu

Zitat von vdrstarter

aber auch Python ist ein Script.

Das ist richtig, aber das kann man als Daemon laufen lassen...
Ich hab kein Problem mit C++, aber für eine Kombination aus DBus und TCP ist mit Python schnell was gemacht, was dann auch tatsächlich funktioniert (inkl. Neuaufbau der TCP-Verbindung usw.).

Ich sag Bescheid, wenn dbus2vdr so weit ist, dass es cStatus nach außen trägt.

Für die, die es interessiert (ist noch nicht im master-Branch und die Osd-Signale fehlen noch):
https://github.com/flensrocker…r/blob/gdbus/status.c#L11

Lars.

Zitat von mini73

Für die, die es interessiert (ist noch nicht im master-Branch und die Osd-Signale fehlen noch):

"    <signal name=\"ChannelSwitch\">\n"
    "      <arg name=\"DeviceNumber\"    type=\"i\" direction=\"out\"/>\n"
    "      <arg name=\"ChannelNumber\"   type=\"i\" direction=\"out\"/>\n"
    "      <arg name=\"LiveView\"        type=\"b\" direction=\"out\"/>\n"
    "    </signal>\n"

Klappt das mit dem LiveView auch mit Software-Frontends?