[solved] TV mit USB-CEC Adapter einschalten - aber nur bei manuellem Start

Entweder du hängst dich ans yaVDR Upstartsystem ran. Dazu hat seahawk1986 hier schon mal was geschrieben: yaUsbIR V3 LIRC USB IR Empfänger/Sender/Einschalter

Oder du installierst dir das uactivity Plugin: http://projects.vdr-developer.…lg-uactivity?jump=welcome
(Wobei ich nicht weiß ob der VDR für den Suspend nun gestoppt wird, das wäre hier Vorraussetzung)

cu

Das uactivity Plugin ist halt wesendlich einfacher, sofern du es als einfach betrachtest ein Plugin zu instalieren. Und der Vorteil ist man muss keine Änderung am System vornehmen, es ist nur eine Konfigdatei im Pluginkonfigordner zu bearbeiten.

In die Upstartsache muss man sich halt erstmal reinarbeiten (da musst du dann einfach durch und einfach mal anfangen), aber die wäre halt DER yaVDR Weg. Das wäre was für Leute die es "richtig" machen wollen, richtig in dem Sinne das man halt generell die yaVDR Methode nutzt wenn man yaVDR nutzt.

Ich empfehle uactivity weils einfacher ist da zum Ziel zu kommen. Es sei denn seahawk1986 sagt dir genau wo du da deine Befehle reinschreiben muss, aber da ändert sich ja auch gerne mal was.

cu

Zitat von duc

das mit dem upstart system hab ich mir schon gedacht, aber wie?
dafür weiß ich zu wenig, wie es funktioniert.

Upstart cookbook

Gerald

Moin!

Sieh dir einfach mal /etc/init/vdr-frontend.conf an, das wertet aus, ob der vdr manuell oder wegen eines Timers gestartet wurde. Entsprechend wird der ATTA-Befehl an softhddevice gesendet. Das ist die Stelle, wo du eingreifen möchtest.

Lars.

Das neue Makefile funktioniert nur mit neueren VDRs.

Am einfachsten ist es die vdr quellen per "apt-get source vdr" zu holen, den pluginquellcode dort drin auszupacken und im Pluginverzeichnis "make -f Makefile.1.6" zu machen. Dann findet sich das Pulgin unter "./PLUGINS/lib".

Ich könnte heute später am Abend auch mal nen Debian Quellpacket (das ist dann sauberer und einfacher) machen wenn du es testen magst (ich hab ekeine Umgebung für diese Art VDR Packete).

cu

Du musst dir halt genau überlegen, worauf du reagieren willst - je nach Hardware-Konstellation und gewünschtem Verhalten kann man da sehr kreativ werden (z.B. durch den yaUsbIr V3 mit angehängter Flip-Flop-Schaltung oder einen eigenen µC/Empfänger speichern, ob der VDR durch einen Fernbedienungsbefehl/Powerbutton angeschaltet wurde und das als zuverlässiges Kriterium abfragen - ermöglicht auch ein WOL-Event zu unterscheiden) oder einfach nur zu schauen gibt es einen Timer oder einen acpiwakeup-Zeitpunkt ohne Timer in den nächsten Minuten...

Zum einfachen Einschalten des TVs wenn das Frontend-Skript annimmt, dass der VDR nicht für einen Timer/acpiwakeup gestartet wurde reicht vermutlich sowas (Einrückungen mit Leerzeichen beachten!) wie hier in Zeile 3 gezeigt aus:

# check if vdr was started because of a timer or an acpi_wakeup event, if not attach frontend
    if settings.manualstart == True and settings.acpi_wakeup != True and settings.conf['start_always_detached'] == '0':
        subprocess.call("echo 'on 0' | cec-client -s /dev/ttyACM0", shell=True, env=settings.env)
        resume(frontend.status())
    else:

https://github.com/yavdr/yavdr…ddevice-02-script.py#L354

Alternativ ein Upstart-Job, der ein "start on started vdr-frontend" als Startbedingung hat und z.B. den Status des Softhddevice-Frontends abfragt...

start on started vdr-frontend


task


script
sleep 1 # ggf. ist eine etwas größere Pause nötig
if [ $(vdr-dbus-send /Plugins/softhddevice plugin.SVDRPCommand string:stat | grep "NOT_SUSPENDED") ]; then 
    echo 'on 0' | cec-client -s /dev/ttyACM0
fi
end script

Zitat von duc

genau so bin ich zu den sourcen von vdr gekommen, mit apt-get source vdr. 1.7.27 ist doch relativ neu. ich glaube nicht, dass es mit dem Makefile.1.6 geht. hab ja 1.7.x als vdr version.

Glaub mir "Makefile.1.6" ist das richtige.

Aber da habe ich mich schön selber verarscht Makefile.1.6 und Makefile.1.7.x ist für den Debian Packetbau extrem nervig Ich muss da erstmal schauen wie man das am besten hinbekommt.

cu

Zitat von Keine_Ahnung

Ich muss da erstmal schauen wie man das am besten hinbekommt.

Einfach einen Patch erstellen, der das richtige Makefile an der erwarteten Stelle erzeugt

Neee, den muss man dann ja bei jeder Änderung nachziehen.

ich habs jetzt mal so

common-build-arch::
	[ -h Makefile ] || ln -s Makefile.1.6 Makefile
	$(MAKE) all $(MAKE_OPTIONS)
	[ -h Makefile ] && rm Makefile


cleanbuilddir::
	[ -h Makefile ] || ln -s Makefile.1.6 Makefile
	$(MAKE) -o .dependencies clean $(MAKE_OPTIONS)
	rm -f libvdr-*.so.*
	[ -h Makefile ] && rm Makefile

Ich werde dann heute Abend das mal richtig schön fertig machen.

cu

Ich wollts eh mal einpacken, für die stillen Mitleser: http://projects.vdr-developer.…jects/plg-uactivity/files

Installation nicht getestet, bugreports willkommen.

Edit: Der versaut die Dateinamen "0.0.1_git593168e7.orig.tar.gz" -> "0.0.1+git593168e7.orig.tar.gz"
Enpacken per "dpkg-source -x vdr-plugin-uactivity_0.0.1+git593168e7-1.dsc", bauen per "dpkg-buildpackage"

cu

Moin!

Kennst du "git describe"? Wenn du Tags in deinem Repository benutzt, ergibt das tolle Versionsnummern, die vor allen Dingen fortlaufend sind. Die git-Revision ist nicht zwingend steigend.

Lars.

Zitat von mini73

Kennst du "git describe"?

Jetzt schon Danke, die Art wie die Nummern gebildet werden gefällt mir.
Ich hatte da gestern auch schon nach ner Policy für "wie bilde ich Versionsnumern vom git" gesucht aber nix gefunden.

Das mit dem Link von
/var/lib/vdr/plugins/uactivity
nach
/etc/vdr/plugins/uactivity
gefällt mir auch noch nicht. Da muss ich auch noch was ändern.

Ist doch gar nicht so einfach die vdr policy in die FHS zu pressen.

cu