Recordingservice verweigert manchmal Abschalten des PC nach Standby

[SnoopyDog]

Hallo! Zunächst nochmal danke für dieses geniale Programm, es läuft wirklich einwandfrei, bis auf ein kleines Problem. Ich hatte zunächst die aktuelle Version 1.5.0.95 installiert und bin wegen dieses Problems testhalber zurück auf die Version 1.5.0.77 - aber leider dasselbe.

 

Zum Problem: manchmal verweigert der Recordingservice ungerechtfertigt das Abschalten des PC in den Standby, sowohl softwaregesteuert (standard auf meinem Server), als auch über den Netzschalter. Im Logfile steht dann immer "QueryStandby Denied". Aufnahmen stehen nicht in der Pipeline und es ist auch kein Client mehr verbunden.

 

Zum Szenario: Ich habe den Recordingservice auf einem kleinen Server installiert, welcher unbeaufsichtigt laufen soll. Tastatur, Maus und Bildschirm sind normalerweise nicht angeschlossen. Der Server hat eine halbwegs große Festplatte, 2 Sat-Karten (die "alten" Skystar HD) und wird bei Bedarf von einem der Clients per WOL aus dem Standby geweckt. Die Clients halten den Server am Leben. Meldet sich kein Client mehr, so fährt er den Server nach 5 Minuten in den Standby. Nach dem Aufwecken rufe ich übrigens die Funktion "SetThreadExecutionState(ES_SYSTEM_REQUIRED OR ES_CONTINUOUS)" auf, weil bei einem unattended Wakeup das System nicht mit dem normalen System-Idle-Timer gestartet wird, sondern einem speziellen unattended-idle-timer, welcher alle 2 Minuten versucht, das System wieder in den Standby zu befördern. Das alles funktioniert seit Monaten 24/7 ohne Probleme.

 

Ich habe die logfiles des Recordingservice angehängt (zuletzt lief wie gesagt testhalber die Version 1.5.0.77).

 

20.03.10 18:11:20.906 QueryStandby Granted ==> Hier hat es geklappt.

21.03.10 00:46:54.031 QueryStandby Denied (und danach, dann hab ich ihn brutal abgewürgt) ==> Nicht o.k.

 

Weiter vorne hab ich übrigens getestet, wie sich der Recordingservice verhält, wenn er den PC aus dem Standby weckt, eine Probeaufnahme macht und gleichzeitig versucht wird, ihn softwaregesteuert in den Standby zu befördern.

 

20.03.10 18:01:20.828 QueryStandby Denied (und folgende) ==> o.k. Hier läuft eine Aufnahme.

 

Normalerweise ist mein Tool zur Serverüberwachung so konfiguriert, daß es nur dann aktiv wird, wenn einer der Clients den Server per WOL geweckt hat. Um den Recordingservice mal zu fordern, hab ich es jedoch umkonfiguriert, so daß es Standby-Anforderungen während einer Aufnahme absetzt. Hat ja auch geklappt.

 

Ich habe das ganze jetzt ein paar Mal mit den beiden oben genannten Recordingservice-Versionen getestet: Scheinbar ist es so, daß der Recordingservice die erste Shutdown-Anfrage nach einem Neuboot noch korrekt behandelt. Erst wenn der PC zum ersten Mal aus dem Standby geweckt wurde (und zwar nicht von ihm selbst, sondern auf andere Weise), verweigert er danach den Standby.

 

Bei einem unattended Wakeup (geht halt nicht anders bei einer Kiste, die nur in der Ecke stehen und funktionieren soll) sendet MS ausschließlich die Message "PBT_APMRESUMEAUTOMATIC". Wenn der Benutzer den PC interaktiv selbst einschaltet, dann zusätzlich noch die Message "PBT_APMRESUMESUSPEND" hinterher. Vielleicht läuft ja hier etwas schief.

logfiles.zip

[dbraner]

Zum Szenario: Ich habe den Recordingservice auf einem kleinen Server installiert, welcher unbeaufsichtigt laufen soll. Tastatur, Maus und Bildschirm sind normalerweise nicht angeschlossen. Der Server hat eine halbwegs große Festplatte, 2 Sat-Karten (die "alten" Skystar HD) und wird bei Bedarf von einem der Clients per WOL aus dem Standby geweckt. Die Clients halten den Server am Leben. Meldet sich kein Client mehr, so fährt er den Server nach 5 Minuten in den Standby. Nach dem Aufwecken rufe ich übrigens die Funktion "SetThreadExecutionState(ES_SYSTEM_REQUIRED OR ES_CONTINUOUS)" auf, weil bei einem unattended Wakeup das System nicht mit dem normalen System-Idle-Timer gestartet wird, sondern einem speziellen unattended-idle-timer, welcher alle 2 Minuten versucht, das System wieder in den Standby zu befördern. Das alles funktioniert seit Monaten 24/7 ohne Probleme.

 

Ich habe fast eine identische Config wie Du. Auch mein Server wird automatisch in den Standby geschickt, wenn kein Client verbunden ist und keine Aufnahme läuft. Ich wecke den Server per WOL jedoch ist ein "SetThreadExecutionState" nicht notwendig. Er geht nicht automatisch wieder ins Standby.

 

Vielleicht ist der Aufruf dieser Funktion die Ursache für die Standby-Verweigerung des Recordingservice. Ich habe aber auch den Verdacht, dass beim Thema Standby, Recordingtimer noch das ein oder andere Verbesserungspotenzial verborgen ist. Ich musste auch lange suchen, bis ich ein Standby Tool gefunden habe, das der RS "unterstütz", d.h. den PC bei einer Aufnahme wieder weckt.

 

Bist Du sicher, dass keine Aufnahme ansteht? Ich habe bei mir festgestellt, dass die Einstellung für das Verhindern des Standby bei anstehender Aufnahme (Zeitintervall) offensichtlich ignoriert wird. Wenn also 5 Minuten eingestellt sind, werden trotzdem geplante Aufnahmen in den nächsten 20 Minuten berücksichtigt.

[SnoopyDog]

Nein, diese Funktion ist nicht die Ursache. Hab sie testhalber auch mal deaktiviert und laut MS ist es ZWINGEND notwendig, sie aufzurufen. Du brauchst sie wahrscheinlich deshalb nicht aufzurufen, weil das der Recordingservice ebenfalls macht. Aber wenn Du einen PC ohne Maus, Tastatur, Bildschirm, Windows XP in der Ecke stehen hast, keinerlei Software installiert hast, die ins Powermanagement eingreift und ihn per WOL aufweckst, so wird er nach 2 Minuten vom Betriebssystem heruntergefahren, glaub mir Ausnahme: Du schließt nach dem WOL Maus und/oder Tastatur an und machst ein paar Eingaben, dann macht das System (Windows) dasselbe, wie "SetThreadExecutionState": den unattended-idle-Timer beenden und den System-idle-Timer aktivieren. Das ist alles bei Microsoft dokumentiert, funktioniert auch so wie dokumentiert und es gibt auch nichts dran zu deuten.

 

Und ja, ich schreibe nur Sachen hier, von denen ich mir 100% sicher bin (naja, meistens ).

 

Ich hab das hier auch mehr als Fehlermeldung für Lars reingestellt.

Edited March 21, 2010 by SnoopyDog

[Lars_MQ]

Das ist wohl noch ein client aktiv beim standby.

[SnoopyDog]

Hm, ich hatte alles ausgeschaltet. Der DVBViewer wird am Client eigentlich immer sauber beendet beim Herunterfahren (?)

 

D.h. wenn ich im Logfile "ReleaseStandbyblock onClientDisconnect" finde, hat der Recordingservice mitbekommen, daß sich ein Client abgemeldet hat.

 

Noch ein Edit: Ah, Du verwendest das auch "SetThreadExecutionState 0x80000000"

Edited March 21, 2010 by SnoopyDog

[Lars_MQ]

Ich werde dort verstärktes logging einbauen, damit man das besser nachverfolgen kann...

[SnoopyDog]

OK, zusätzliche Logmeldungen sind niemals schlecht Und ich werde erstmal weiter suchen, was es sein könnte. Ansonsten rennt das Ding wirklich super!

[dbraner]

Nein, diese Funktion ist nicht die Ursache. Hab sie testhalber auch mal deaktiviert und laut MS ist es ZWINGEND notwendig, sie aufzurufen. Du brauchst sie wahrscheinlich deshalb nicht aufzurufen, weil das der Recordingservice ebenfalls macht. Aber wenn Du einen PC ohne Maus, Tastatur, Bildschirm, Windows XP in der Ecke stehen hast, keinerlei Software installiert hast, die ins Powermanagement eingreift und ihn per WOL aufweckst, so wird er nach 2 Minuten vom Betriebssystem heruntergefahren, glaub mir

 

Mein PC steht zwar nicht in der Ecke, aber im Keller. Ohne Maus, Tastatur und sonstwas. Aber wenn der RS sowieso SetThreadExecutionState aufruft, warum musst Du das nochmal machen? Ansonsten ist bei Microsoft auch beschrieben, dass man das System mit SetSuspendState ins Standby schicken soll. Das funktioniert mit dem RS auch nicht.

 

Du kannst Dir das SetThreadExecutionState schenken, wenn Du unter Systemsteuerung -> Energieoptionen das Schema "Minimaler Energieverbrauch" aktivierst und dann bei "Standby" die Einstellung "nie" auswählst. Das verhindert das automatische Standby beim Rum-Idlen

 

Und ja, ich schreibe nur Sachen hier, von denen ich mir 100% sicher bin (naja, meistens ).

 

Würde ich nie wagen zu bezweifeln.

 

Ich hab das hier auch mehr als Fehlermeldung für Lars reingestellt.

 

Naja, ich hoffe ich darf mich trotzdem weiter an der Diskussion beteiligen.

Edited March 21, 2010 by dbraner

[SnoopyDog]

@Lars: Ich lasse morgens während der Arbeit oft noch nebenbei den DVBViewer über WLAN auf dem Notebook laufen. Leider ist das WLAN des Notebook ein wenig instabil und bricht hin und wieder einfach zusammen, so daß ich es aus- und wieder einschalten muß. Könnte es sein, daß hierdurch ein Client nicht sauber abgemeldet wird?

 

@dbraner:

Aber wenn der RS sowieso SetThreadExecutionState aufruft, warum musst Du das nochmal machen?

Den Recordingservice hab ich erst vor ein paar Tagen installiert, mein Tool, welches den Server verwaltet, gibt es schon ein paar Jahre und funktioniert 24/7 ohne Probleme, hat mit dem DVBViewer nichts zu tun und soll (muß) auch ohne den DVBViewer funktionieren. Und es ist auch nicht schlimm, wenn man diese Funktion mehrmals aufruft...

 

Ansonsten ist bei Microsoft auch beschrieben, dass man das System mit SetSuspendState ins Standby schicken soll.

Genau das macht mein Tool (es gibt übrigens keinen anderen Aufruf, um das zu tun, nur der Parameter "ForceCritical" hat es in sich), hat aber nichts damit zu tun, daß man nach einem unattended Wakeup des PC "SetThreadExecutionState" mit geeigneten Parametern aufrufen muß, um das automatische Herunterfahren des PC durch den unattended-Idle-Timer von Windows, welcher nach einem unattended Wakeup wie z.B. WOL oder Waitable Timer aktiv ist, zu verhindern.

 

Du kannst Dir das SetThreadExecutionState schenken, wenn Du unter Systemsteuerung -> Energieoptionen das Schema "Minimaler Energieverbrauch" aktivierst und dann bei "Standby" die Einstellung "nie" auswählst. Das verhindert das automatische Standby beim Rum-Idlen

Nein, nicht nach einem unattended Wakeup. Das geht nur, wenn der normale System-Idle-Timer aktiv ist (wie bei MS dokumentiert).

 

Naja, ich hoffe ich darf mich trotzdem weiter an der Diskussion beteiligen.

Warum denn nicht? Wenn das eigentliche Problem dadurch nicht untergeht. Edited March 22, 2010 by SnoopyDog

[Lars_MQ]

Könnte es sein, daß hierdurch ein Client nicht sauber abgemeldet wird?

Ja, das kann durchaus sein.

[SnoopyDog]

@Lars: Danke, dann werde ich mal versuchen, der Sache weiter nachzugehen (aber wohl eher am Wochenende)

 

@dbraner: Sorry, wenn ich vielleicht mißverständlich rüberkam

[Lars_MQ]

Ich bin auch dabei das zu untersuchen. Ich hab mal spasseshalber das wlan am Laptop während einer wiedergabe gekillt, der service erkennt, das die verbindung zusammen gebrochen ist und entfernt die clients.

 

Ich werde die nächste version sicherlich vor dem WE hochladen, damit lässt es sich sicherlich besser testen.

[filmgetter]

Soweit ich weiß, testet ihr ja auch mit Win7.

 

Könnte es sein, dass irgendein Windows Event oder vielleicht auch ein anderes Event (Softwareupdate) nach dem Aufwachen zur Aufnahme den Standby verhindert.

 

Bei mir ist es so, dass der Rechner aus dem Standby vom Recording Service zur Aufnahme geweckt wird. Wenn ich dann während der Aufnahme am Rechner rumspiele und während der Aufnahme dann den TV wieder ausschalte, scheint der Recording Service die Einstellung "nach der Aufnahme ""Standby"" zu ignorieren.

 

Wenn Windows 7 zu der Zeit, in der die Aufnahme eigentlich beendet werden würde, noch einen Prozess ausführt, z. B. Festplatte defragmentieren oder weiß der Henker was da alles automatisiert abläuft, könnte doch auch dadurch der Standby verhindert werden, oder? Ich verwende jeweils die neusten Beta vom DVBV und RS.

[SnoopyDog]

Hallo filmgetter! Ich verwende Windows XP und das den Standby verhindert der Recording-Service selbst. Normalerweise gewollt und 100% korrekt, aber in meinem Fall ist wohl etwas schief gelaufen...

[dbraner]

Soweit ich weiß, testet ihr ja auch mit Win7.

 

Könnte es sein, dass irgendein Windows Event oder vielleicht auch ein anderes Event (Softwareupdate) nach dem Aufwachen zur Aufnahme den Standby verhindert.

 

Ich bin gerade dabei ein kleines Progrämmchen zu schreiben, das im Hintergrund läuft und alle relevanten Power-Management-Messages abfängt und protokolliert. Dazu noch eine Möglichkeit, Dinge wie IsSystemResumeAutomatic nach einem Wakeup abzufragen.

 

Unter XP sollte es auch möglich sein, einen Hook für SetThreadExecutionState, SetSuspendState und CreateWaitableTimer zu installieren, um zu sehen, wann welche Funktion aufgerufen wird.

 

Das bringt - zumindest für mich - hoffentlich etwas mehr Klarheit in das Verhalten bei Standby und Resume.

 

Momentan funktioniert bei mir zwar alles wie es soll, es stört mich aber, wenn ich nicht genau weiß, warum das so ist

[kicr]

Ich bin gerade dabei ein kleines Progrämmchen zu schreiben, das im Hintergrund läuft und alle relevanten Power-Management-Messages abfängt und protokolliert. Dazu noch eine Möglichkeit, Dinge wie IsSystemResumeAutomatic nach einem Wakeup abzufragen.

 

Das hört sich interessant an, ich habe derzeit das Problem das mein HTPC nach dem herunterfahren öfters direkt wieder hochfährt. Manchmal geht er aber auch ganz normal aus. Dabei ist es egal ob ich den PC aus dem DVBViewer herunterfahre oder ganz normal über Start > Herunterfahren.

[filmgetter]

@dbraner

 

Ja, das Proggie wäre auch was für mich; es gibt zwar unter Win7 die Möglichkeit der Fehlerprotokollierung und dieverse Powercfg -hastDunichtgesehen Befehle, aber für mich ist das nicht überschaubar genug.

 

Ich hatte mich mal vor einer Weile durch die Events gekämpft und viele, viele Trigger durchgeschaut, aber das dauert ja Wochen! Gestern habe ich dann z. B. ein Programm entdeckt, (mcshoutcast vom Fremdgehen mit Windows Media Center), welches immer um 02.47 Uhr MEZ Updates gesucht hat.

 

Das hat dann unter Umständen zwar nicht den Standby verhindert, mich das aber glauben lassen. Nee, das Proggie hat jede Nacht den PC aus dem Standby geholt und war dann nicht in der Lage, Windows7 anschließend wieder runterzufahren.

 

Nach dem Deaktivieren des Trigger war der Rechner heute Morgen jedenfalls aus. Gott seis gedankt.

 

@kicr

 

Bei Dir läuft auch ein Prozess. Leider kann man nicht alle sehen. Insofern wäre ein Programm, wie von Dbraner mit Sicherheit eine Hilfe.

 

Gruß

[dbraner]

Das hört sich interessant an, ich habe derzeit das Problem das mein HTPC nach dem herunterfahren öfters direkt wieder hochfährt. Manchmal geht er aber auch ganz normal aus. Dabei ist es egal ob ich den PC aus dem DVBViewer herunterfahre oder ganz normal über Start > Herunterfahren.

 

Das hört sich eher nach einer BIOS Einstellung an. Dort kann man angeben, welche Hardware-Ereignisse einen PC aufwecken. Normalerweise ist dort eingestellt, dass alle möglichen USB-Devices (Maus, Tastatur) den PC aufwecken können. Das sollte man abschalten. Gerade an die Maus kommt man doch gerne mal dran.

[kicr]

Das habe ich mir auch schon gedacht. Bin nur leider noch nicht dazu gekommen...Dennoch würde mich dein Programm interessieren. Ist mit Windows 7 doch wie schon gesagt unübersichtlicher...

[kicr]

Habe gestern Abend nochmal sämtliche BIOS Einstellungen überprüft. Hier ist alles deaktiviert was den Rechner aufwecken könnte. Vielleicht hat ja jemand noch spontan eine Idee. Sonst werde ich mal einen neuen Thread eröffnen.

[filmgetter]

Wie gesagt, es ist ein Programm, welches Deinen PC weckt, da verwette ich meine Ei......

[dbraner]

Das habe ich mir auch schon gedacht. Bin nur leider noch nicht dazu gekommen...Dennoch würde mich dein Programm interessieren. Ist mit Windows 7 doch wie schon gesagt unübersichtlicher...

 

Schau Dir mal Systemsteuerung -> Verwaltung -> Aufgabenplanung an. Blende alle Aufgaben ein. Du wirst zig Aufgaben finden, die Windows irgendwann mal ausführt. Eine dieser Aufgaben könnte es sein, die Deinen PC aufweckt.

 

Einfach mal die Konfig der einzelnen Aufgaben anschauen. Die üblichen Verdächtigen sind irgendwelche automatischen Updates o.ä.