[yaVDR 0.5 alpha1] Feature-Request - SoftHDDevice Suspend bei Timer-Start bzw. Beenden

Denkbar ist das schon, wobei der Aufwand nicht zu unterschätzen ist. Wir haben schließlich 4 Frontends, die sich vergleichbar verhalten sollten.

Ich denke aber das wird nichts mehr für die Version 0.5

Gerald

Man könnte es ja auf jeden Fall schon mal als individuelle Lösung erarbeiten und schauen wie gut es sich macht. XBMC und die TT S2-6400 sind sicherlich Sonderfälle, die man separat behandeln muss ( bei XBMC geht es IMHO hauptsächlich um die Reduzierung der Systemlast bei ruhender Oberfläche (siehe Ende dieses Posts [yaVDR 0.5-alpha1] Tester gesucht: yaVDR-Tools XBMC-Addon), für den Rest (softhddevice, xine und xineliboutput) dürfte das recht einheitlich klappen.

Eine Idee wäre ein Python-Skript in die vdr-frontend.conf zu integrieren, das das Attachen/Detachen bzw. das Starten/Stoppen des jeweiligen Frontends übernimmt und zusätzlich auf dem Socket von Eventlircd lauscht und die Fernbedienung für den VDR (de)aktiviert - wenn ich mal Zeit und Lust habe kann ich ja mal schauen.

Moin!

Wie viele tausend Stunden muss man denn aufnehmen, damit sich die Stromersparnis rentiert? SCNR

Bei softhddevice ist ein weiteres Programm, dass das Frontend aktiviert, doch eigentlich gar nicht nötig, wenn es nicht im Status "DETACHED", sondern "SUDPENDED" ist. Dann reaktiviert es sich doch von alleine, oder?
Und wer sagt, dass wir dieses Feature denn für alle Frontends anbieten müssen?

Meine Befürchtung ist, dass das ganze System immer anfälliger wird, je mehr Programme da gegenseitig sich versuchen, zu aktivieren und zu deaktivieren...

Lars.

Zitat von mini73

Wie viele tausend Stunden muss man denn aufnehmen, damit sich die Stromersparnis rentiert? SCNR

Die Frage ist eher nach dem Aufwand das Einzubauen vs. dem durch die Gesamtheit der yaVDR-Nutzer (die das nutzen wollen) gesparten Strom

Zitat von mini73

Bei softhddevice ist ein weiteres Programm, dass das Frontend aktiviert, doch eigentlich gar nicht nötig, wenn es nicht im Status "DETACHED", sondern "SUDPENDED" ist. Dann reaktiviert es sich doch von alleine, oder?

Aktuell haben wir mit dem Stand in yaVDR 0.5 beim softhddevice zwei hausgemachte "Probleme":

• Wir starten softhddevice detached, durch das immer stattfindende Attachen des Frontends nach dem Start des VDR, Verfügbarkeit der Soundkarte(n) und Openbox erzeugt Benutzeraktivität, der Brückentimer des VDR greift dadurch nicht mehr.
• Falls man ermöglichen will, dass der Benutzer XBMC zusätzlich über unsere bislang eingesetzen Upstart-Skripte starten kann (und das nicht nur bei attachtem Frontend erfolgen soll), muss für den VDR die Fernbedienung deaktiviert werden und das Frontend muss soweit ich weiß detached sein, damit es sich nicht z.B. durch OSD-Meldungen aufgrund von Timerkonflikten usw. selbstständig reaktiviert.

Dass die Sache dadurch etwas komplexer wird ist nicht abzustreiten, aber da haben wir ja noch ganz andere Besonderheiten in yaVDR...

Die Benutzeraktivität durch das Attachen lässt sich auch wegpatchen - bzw sollte johns herausnehmen, da für den Anwendungsfall unpassend.
Das bei Timeraufnahmen das Frontend nicht gestartet wird, finde ich nicht wahnsinning wichtig. Die Ersparnis ist nicht besonders groß,
die Grafikkarte verbraucht ja trotzdem Strom auch wenn sie nur ein dummes Bild anzeigt.

Moin!

Zitat von seahawk1986

Die Frage ist eher nach dem Aufwand das Einzubauen vs. dem durch die Gesamtheit der yaVDR-Nutzer (die das nutzen wollen) gesparten Strom

Hat das mal jemand nachgemessen?

In dem anderen Thread geht es ja um eine passive Grafikkarte. Nur weil die keinen Lüfter montiert hat, heißt das nicht, dass sie ohne Luftstrom vernünftig funktioniert.
Bei passiven Komponenten muss man selbst dafür sorgen, dass die Wärme vernünftig aus dem Gehäuse abgeführt wird.

Ich hab ja nichts dagegen, dass an sowas gebastelt wird, ich versuche nur, die Featurewünsche für 0.5 etwas einzudämmen, sonst wird das nie was...
Und es hilft nicht gegen falsch konzipierte Gehäuse (wenn das denn die Ursache ist).

Das mit der Benutzeraktivität beim ATTA schau ich mir mal an.

Lars.

Zitat von mini73

Hat das mal jemand nachgemessen?

johns hatte da mal was gepostet: Sandy Bridge Projektvorstellung, Tests und Energieverbrauch - je nachdem was für ein Sender eingestellt ist, können das schon mal gut 10W Unterschied sein.

Moin!

Zitat von seahawk1986

können das schon mal gut 10W Unterschied sein

Ok, dann lohnt es sich.

Wollen wir das für alle Frontends? Oder reicht softhddevice (einfach ein SUSP nach dem ATTA schicken, wenn Timerstart)?
Dann müsste man sich um nichts weiter kümmern.

Als Alternative zum Patchen von softhddevice könnte ich auch noch was in dbus2vdr einbauen, da der vdr eine Funktion anbietet, die Benutzeraktivität manuell auszuschalten.
Das könnte man dann bei einem Timerstart nach dem Attachen von softhddevice aufrufen (in der Klasse cShutdownHandler gibt's ein SetUserInactive).
Und vielleicht ist das ja auch für andere Frontends bzw. andere Situationen interessant.

Lars.

Zitat von mini73

Oder reicht softhddevice (einfach ein SUSP nach dem ATTA schicken, wenn Timerstart)?
Dann müsste man sich um nichts weiter kümmern.

Kann man denn aus dem SUSPEND heraus ein DETACH machen? Das wäre für XBMC und andere Anwendungen solange wir nur Alsa für die Tonausgabe haben glaube ich wichtig...

Zitat von mini73

Das könnte man dann bei einem Timerstart nach dem Attachen von softhddevice aufrufen (in der Klasse cShutdownHandler gibt's ein SetUserInactive).
Und vielleicht ist das ja auch für andere Frontends bzw. andere Situationen interessant.

Gegen neue Funktionen in dbus2vdr habe ich nie etwas

Moin!

Zitat von seahawk1986

Kann man denn aus dem SUSPEND heraus ein DETACH machen? Das wäre für XBMC und andere Anwendungen solange wir nur Alsa für die Tonausgabe haben glaube ich wichtig...

Ich glaube, momentan geht das (noch) nicht, aber per STAT lässt sich abfragen, wo softhddevice gerade ist, dann kann vorher noch ein RESU geschickt werden.
Es stört wahrscheinlich aber auch nicht, wenn man einfach mal auf Verdacht ein RESU vor dem DETA schickt...

Auf der anderen Seite würde ich es auch nicht als verkehrt ansehen, wenn aus dem SUSPEND heraus direkt ein DETACH funktionieren würde.
Müssen wir mal testen und ansonsten mach ich bei Gelegenheit einen Patch fertig.

Lars.

Also hier mal was zu Spielen für die /etc/init/vdr-frontend.conf (für softhddevice - damit es einfacher bleibt, ist erstmal alles in der Upstart-Datei, man kann das aber auch problemlos in ein externes Skript auslagern): http://paste.ubuntu.com/1107760/

Das Frontend wird nur attached, wenn der VDR denkt, dass er von Hand, aber nicht durch einen Timer gestartet wurde.
KEY_PROG1 (de)aktiviert das Softhddevice-Frontend
KEY_POWER2 deaktiviert das Frontend (falls aktiv) und fordert den VDR zum Herunterfahren auf.
Drück man eine beliebige Taste (außer KEY_POWER2) wird das Frontend wieder attached.

Moin!

Und das gerade in unstable veröffentlichte dbus2vdr 0.0.8a kennt nun auch

vdr-dbus-send /Shutdown shutdown.SetUserInactive

Ist aber ungetestet, bin noch auf Arbeit und konnte nur eben remote programmieren...

Lars.

svdrpsend hitk power ist einfacher

Der VDR fährt ja sofort runter wenn du das absetzt.

cu

Zitat von Keine_Ahnung

svdrpsend hitk power ist einfacher

Ja, aber dafür sollte man während einer Aufnahme dann nicht immer diese "Der VDR fährt in X Minuten runter" Meldungen haben

Zitat von seahawk1986

Ja, aber dafür sollte man während einer Aufnahme dann nicht immer diese "Der VDR fährt in X Minuten runter" Meldungen haben

Hat man bei hitk power auch nicht. Das macht aus Sicht des VDR nämlich wirklich genau das selbe

Der Witz ist das ich hier noch nen Patch (Datiert von Januar) für dbus2vdr liegen habe der SetUserInactive einbaut. Ich hielt das für ne Super Idee weil man dann den VDR per FB mal eben auf Benutzer inaktiv setzen kann (weil mein Ausgabeplugin dann von Haus aus die Videoausgabe suspendet). Ich habe dann ziemlich blöd geschaut als mir beim Test der VDR runtegefahren ist. Funktionierte dann doch nicht wie erwartet

Wenn SoftHDDevice bei Atachen Nutzeraktivität triggert dann sollte das da raus. Das ist dann ja wohl einfach nen Bug.

cu

Moin!

Zitat von Keine_Ahnung

Ich habe dann ziemlich blöd geschaut als mir beim Test der VDR runtegefahren ist. Funktionierte dann doch nicht wie erwartet

Liegt das an dem anderen Timeout? Oder bist du der Sache nicht auf den Grund gegangen?

Zitat von Keine_Ahnung

Wenn SoftHDDevice bei Atachen Nutzeraktivität triggert dann sollte das da raus. Das ist dann ja wohl einfach nen Bug.

Das denke ich auch, hatte aber noch keine Zeit, die Stelle zu suchen.

Lars.

Zitat von Keine_Ahnung

Hat man bei hitk power auch nicht. Das macht aus Sicht des VDR nämlich wirklich genau das selbe

Ich habs grade in einer VM laufen lassen - bei einem aktiven Timer bringt ein HITK POWER eine OSD-Meldung, dass gerade ein Timer läuft, das reine vdr-dbus-send /Shutdown shutdown.SetUserInactive hingegen setzt einfach stumm den User inaktiv.

Zitat von Keine_Ahnung

Wenn SoftHDDevice bei Atachen Nutzeraktivität triggert dann sollte das da raus. Das ist dann ja wohl einfach nen Bug.

Kommt drauf an, was man haben will - wenn man sagt man will das Frontend nur laufen lassen, wenn der User aktiv ist (was ja durchaus ein paar Watt sparen kann und bei Systemen mit nur einem Tuner z.B. die Nutzung von xvdr und Streamdev von anderen Rechnern aus erleichtert), dann ist das Verhalten eigentlich ganz praktisch.

Beim mir habe ich das folgende Skript als upstart-job eingebunden (allerdings noch unter yavdr0.4):

#!/bin/sh 
# aZeit = Aktuelle Zeit
Timer=`grep NextWakeupTime /etc/vdr/setup.conf | cut -c 18-27`
echo $Timer 
aZeit='date +%s'
echo $aZeit
if [ $Timer - $aZeit < 300 ]
then
  @suspendoutput 
  echo "nächster timer in weniger als 5min! bild/ton werden gemutet!"
else
  echo "nächster timer in mehr als 5min! bild/ton werden angezeigt!"
fi

Mich hat die Stromersparnis nicht interessiert. Wenn der TV mitten in der Nacht hell wird und über den Verstärker losbrüllt...