tvtime über Script starten/beenden - brauche Hilfe!

Hallo!

Bin noch ziemlich unerfahren auf dem Gebiet der Script-Programmierung (Programmieren an sich kann ich eigentlich, nur eben in anderen Sprachen ), und hab mir ein kleines Script geschrieben um auf meinem Rechner mit Hilfe der Power-Taste auf der FB tvtime ein- bzw. ausschalten zu können:

#!/bin/bash


if [ -z "$(ps -A | grep -w tvtime)" ]
then
  tvtime &
else
  killall tvtime
fi


exit 0

Das Script ist über die commands.conf in den VDR eingebunden, und in der keymacros.conf lasse ich über User9 (darauf hab ich meine Power-Taste gelegt) das Befehls-Menü aufrufen und "Ok" drücken (falls hier jemand einen einfacheren Weg weiß, ich bin für sowas offen ).

Von der Shell aus jedenfalls funktioniert das Script ohne Probleme, und das Beenden von tvtime über die FB läuft auch. Nur beim Starten macht er Schwierigkeiten, scheinbar wird tvtime nicht wie geplant im Hintergrund gestartet sondern blockiert die Beendung des Scriptes, womit auch der VDR blockiert ist und auf nichts mehr reagiert (es wird immer noch das OSD mit dem Befehlsmenü eingeblendet, und keine Taste bewirkt etwas). Erst wenn ich das tvtime-Fenster von Hand schließe arbeitet auch VDR weiter. Wo könnte hier das Problem liegen?

Wirklich gerade kein Experte hier verfügbar der mir etwas unter die Arme greifen könnte?

Danke, hatte den Thread vor längerer Zeit schon mal entdeckt, hatte ihn jetzt aber nicht wiedergefunden als ich das gleiche Problem hatte. 'echo "tvtime" | at now' hab ich allerdings schon längst getestet, da streikt aber leider tvtime weil die Variable DISPLAY nicht gesetzt ist. Hatte versucht die Variable im Aufruf gleich mit zu setzen, aber da hatte ich wohl 'nen Fehler drin wie ich grad bei meinen Tests auf 'nem anderen Rechner festgestellt hab, muss ich heut abend gleich nochmal probieren.

Ok, hat jetzt wirklich hingehauen nachdem ich das mit der DISPLAY-Variable korrekt gelöst gehabt:

#!/bin/bash


if [ -z "$(ps -A | grep -w tvtime)" ]
then
  echo "export DISPLAY=:0.0 && tvtime" | at now
else
  killall tvtime
fi


exit 0

Was mir jetzt eigentlich noch fehlt ist ein gleichzeitiges automatisches Unmute/Mute, natürlich abhängig vom aktuellen Status um nicht z.B. beim Beenden von tvtime einen bereits stumm geschalteten Ton wieder laut zu schalten

Danke mapovi, kann zwar deine Variante nicht so direkt übernehmen da ich nicht LIRC nutze sondern den IR-Empfänger meiner Nexus-s und das remote-Plugin, aber der Denkanstoß in Richtung SVDRP war genau das richtige Mein Script sieht momentan jetzt so aus:

#!/bin/bash


if [ -z "$(ps -A | grep -w tvtime)" ]
then
  echo "export DISPLAY=:0.0 && tvtime" | at now
  if ! [ -z "$(svdrpsend.pl VOLU | grep -w mute)" ]
  then
    echo "svdrpsend.pl VOLU mute" | at now
  fi
else
  killall tvtime
  if [ -z "$(svdrpsend.pl VOLU | grep -w mute)" ]
  then
    echo "svdrpsend.pl VOLU mute" | at now
  fi
fi


exit 0

Deine Variante mit VOLU 0 und VOLU 255 haut zwar auf jeden Fall hin, allerdings kann ich so nicht wieder die vorherige Lautstärke wiederherstellen sondern immer nur auf die im Script einprogrammierte lautschalten. Deshalb die Variante mit VOLU mute. Allerdings macht mir der Test auf die aktuelle Lautstärke Schwierigkeiten, bei aufgeregelter Lautstärke bekomme ich normalerweise "Audio volume is xxx" zurück, bei stummgeschaltetem Ton "Audio is mute". Wenn ich das Script von der Konsole aufrufen klappt auch alles wunderbar, wenn ich das Script aber über den VDR starten lasse ergibt sich folgendes Verhalten:

- beim Einschalten wird der Ton grundsätzlich nicht laut geschalten, egal ob er vorher stumm war oder nicht
- beim Ausschalten wird der Ton immer umgeschalten, egal ob er vorher lief oder stumm war

Die Ursache dafür hab ich auch recht schnell gefunden, wenn ich in dem Script noch folgende Zeie einfüge:
echo "($svdrpsend.pl VOLU)" > /video/vol.txt
erhalte ich beim manuellen Aufruf des Scriptes folgenden Inhalt in vol.txt:

220 *** SVDRP VideoDiskRecorder 1.3.35; Sun Nov 13 09:03:19 2005
250 Audio is mute
221 *** closing connection

bzw.

220 *** SVDRP VideoDiskRecorder 1.3.35; Sun Nov 13 09:03:36 2005
250 Audio volume is 170
221 *** closing connection

Wenn ich das Script dagegen wieder über VDR ausführen lasse steht in der Datei plötzlich nichts drin! Das bedeutet natürlich dass grep niemals das Wort "mute" in der Ausgabe finden kann, wenn überhaupt nichts zurückgegeben wird Was mache ich falsch, oder habe ich irgendetwas übersehen?

Ein weiteres Problem ist noch dass das Abfragen der aktuellen Lautstärke im Script enorm viel Zeit benötigt, mein VDR ist dadurch jeweils bis zu 10 Sekunden außer Gefecht gesetzt und wartet auf die Beendigung des Kommandos. Gibt es eventuell noch eine andere Möglichkeit herauszubekommen ob der Ton gerade stumm geschalten ist oder nicht? Das würde dann wahrscheinlich gleich noch mein erstes Problem mit beseitigen.

Zitat

... damit das zuverlässig geht muss man aber noch ein paar Abfragen einbauen (z.B. wenn man mutet sollte es nicht schon gemutet sein...), da das sonst ein Blindflug wird.

Genau das erreiche ich ja (normalerweise) über die Abfrage

if [ -z "$(svdrpsend.pl VOLU | grep -w mute)" ]

(überprüfen ob in der Ausgabe von svdrpsend.pl VOLU "mute" drin vorkommt, damit ist eindeutig der Zustand der Lautstärke gekennzeichnet) Das Problem hierbei ist ja nur dass beim Aufruf über VDR überhaupt kein Text zurückgegeben wird, also kann ich auch nichts auswerten. Der Mute-Befehl speichert ja schon von selbst die alte Lautstärke, die muss man nicht erst in einer Datei sichern und später wieder herstellen (der Gedanke war mir nämlich auch zuerst gekommen, aber ist ja nicht nötig). Aber auch dein Script schlägt an derselben Stelle fehl, in der vol.txt steht nämlich absolut nichts drin. Allerdings aber nur wenn ich es über VDR starten lasse, bei einem normalen Aufruf von der Konsole klappt alles

Starte es als normaler User von der Konsole, sowohl als einfacher Aufruf als auch mit sudo. Klappt aber auch als root. VDR läuft auch als root (hab mir noch nicht die Mühe gemacht 'nen eigenen User dafür einzurichten), weiß also im Moment nicht wo das Problem liegen könnte.