Jens Remus Posted May 28, 2012 Posted May 28, 2012 Hallo liebe RS-Entwickler! Gestern ist mein HTPC trotz laufender Aufnahme im Recording Service (RS) und aktiviertem AwayMode nach einem Klick auf "Energie sparen" (Startmenü) sofort in den Standby-Modus gewechselt. Bisher wechselte mein HTPC dann in den AwayMode und wurde erst nach Abschluss der Aufnahme durch den RS in den Standby-Modus geschickt. Konfiguration: Windows 7 Home Premium 32-Bit SP1 DVBViewer 4.9.6.20 DVBViewer Recording Service 1.9.6.0 Ich hatte zwei direkt aufeinanderfolgende Aufnahmen auf ARD HD geplant, die sich jedoch aufgrund von Vor- und Nachlaufzeit 15 Minuten überschnitten: Tatort (Timer: 20:10 - 21:55) und anschließend Sherlock (Timer: 21:40 - 23:25). Nach Beginn des ersten Timers (Tatort) habe ich nebenher eine andere Aufnahme geschaut und nach Ende des ersten und vor Ende des zweiten Timers (Sherlock) den HTPC per "Energie sparen" in den AwayMode/Standby geschickt. Der HTPC befand sich nachmittags im Standby und hat sich laut RS-Log am 27.05. um 20:07 eingeschaltet (RS: Resume PBT_APMRESUMEAUTOMATIC - EventGhost: System.ResumeAutomatic), um mit der Aufnahme vom Tatort um 20:10 zu beginnen. Kurz nach 21 Uhr (laut RS-Log um 21:08) habe ich parallel per DVBViewer angefangen eine alte Aufnahme anzuschauen (RS: Resume PBT_APMRESUMESUSPEND - EventGhost: System.Resume). Laut RS-Log begann der RS um 21:40 die Aufnahme von Sherlock und um 21:55 beendete er die Aufnahme vom Tatort. Nachdem ich gegen 22:51 mit dem Gucken der alten Aufnahme fertig war, habe ich den HTPC per Klick auf "Energie sparen" im Windows Startmenü in den AwayMode schicken wollen, stattdessen hat er sich jedoch sofort in den Standby-Mode versetzt. Grüße aus Stuttgart und vielen Dank für das tolle Programm, Jens support.zip
Jens Remus Posted June 3, 2012 Author Posted June 3, 2012 Mittlerweile habe ich auf die aktuelle Version 1.9.7.0 des DVBViewer Recording Service geupdated und das Problem auch damit reproduzieren können: support.zip am 30.05.12 ab 20:26 Uhr Ich habe zwei sich teilweise überlappende Aufnahmetimer auf einem Sender programmiert. Der RS hat den HTPC für den ersten Aufnahmetimer aus dem Standby geholt. Während der ersten Aufnahme habe ich nebenher mit dem DVBViewer eine Aufnahme aus der Konserve abgespielt. Noch vor Ende der zweiten Aufnahme habe ich dann den HTPC per "Energie sparen" in den Standby geschickt, was vom RS nicht verhindert wurde, d.h. der HTPC ist nicht in den Away-Mode gewechselt. Mein Verdacht war ursprünglich, dass der RS aufgrund der sich teilweise überschneiden Aufnahmetimer den Standbyblock nach Ende des ersten Timers fälschlicherweise freigibt, obwohl noch ein weiterer Aufnahmetimer aktiv ist, und dass es gar nichts mit dem parallelen Anschauen einer Aufnahme im DVBViewer während der Aufnahmen des RS zu tun hat. Das RS-Log deute ich als Laie jedoch so, dass das manuelle Aufwecken nach Beginn des Aufnahmetimers fälschlicherweise den RS dazu bringt seinen Standbyblock freizugeben: 30.05.12 20:52:11.838 No shutdown allowed next recording: 30.05.2012 20:55:00 30.05.12 20:52:11.838 SetStandbyblock PBT_APMRESUMESUSPEND [...] 30.05.12 20:55:02.557 SetStandbyblock TRecording [...] 30.05.12 21:16:23.113 Resume PBT_APMRESUMESUSPEND 30.05.12 21:16:23.114 Resume Processing... 30.05.12 21:16:23.114 ReleaseStandbyblock PBT_APMRESUMESUSPEND [...] 30.05.12 22:29:06.128 Standby PBT_APMSUSPEND 30.05.12 22:29:06.128 Setting next recording: 31.05.2012 20:06:00 Liegt es an meiner HTPC-Konfiguration oder ist es ein Fehler im RS? Wie könnte ich das Problem weiter debuggen? Gibt es ein Tool, mit dem ich sehen kann, ob irgenein Programm den Standby blockiert und in den Away-Mode umleitet? Vielen Dank im Voraus, Grüße aus Stuttgart, Jens
Jens Remus Posted June 3, 2012 Author Posted June 3, 2012 Das RS-Log deute ich als Laie jedoch so, dass das manuelle Aufwecken nach Beginn des Aufnahmetimers fälschlicherweise den RS dazu bringt seinen Standbyblock freizugeben: [...] Liegt es an meiner HTPC-Konfiguration oder ist es ein Fehler im RS? Wie könnte ich das Problem weiter debuggen? Gibt es ein Tool, mit dem ich sehen kann, ob irgenein Programm den Standby blockiert und in den Away-Mode umleitet? Ich antworte mir mal selber, da ich noch etwas weiter herumprobiert habe. Bei Microsoft habe ich folgendes Dokument gefunden, was Hinweise zum Debuggen des Windows Power Management gibt: Diagnosing Application Compatibility Issues Affecting Windows Power Management Demnach scheint es tatsächlich so zu sein, dass ein manuelles Aufwecken aus dem Standby (PBT_APMRESUMESUSPEND) nach dem automatischen Aufwecken aus dem Standby (PBT_APMRESUMEAUTOMATIC) durch einen RS-Aufnahmetimer, den RS fälschlicherweise dazu bringt den Standby nicht mehr zu blockieren, d.h. nicht mehr den Wechsel in den Standby in den AwayMode umzuleiten. Ich habe einen Aufnahmetimer erstellt und den HTPC in den Standby geschickt. Rechtzeitig zur Aufnahme wacht er durch den Timer automatisch auf (PBT_APMRESUMEAUTOMATIC). Während der Aufnahme wecke ich ihn nochmals manuell auf (PBT_APMRESUMEAUTOMATIC) und prüfe per powercfg -requests, ob es Anwendungen gibt, die den AwayMode verlangen, was jedoch nicht wer Fall ist: C:\Windows\system32>powercfg -requests DISPLAY: Keine. SYSTEM: [DRIVER] Legacykernelaufrufer AWAYMODE: Keine. Plane ich hingegen im laufenden Betrieb einen Aufnahmetimer und prüfe per powercfg -requests den Status sobald der RS mit der Aufnahme begonnen hat, so ist er korrekt für den AwayMode registriert: C:\Windows\system32>powercfg -requests DISPLAY: Keine. SYSTEM: [sERVICE] \Device\HarddiskVolume2\Program Files\DVBViewer\DVBVservice.exe (DVBVRecorder) [DRIVER] Legacykernelaufrufer AWAYMODE: [sERVICE] \Device\HarddiskVolume2\Program Files\DVBViewer\DVBVservice.exe (DVBVRecorder) Grüße aus Stuttgart, Jens
Jens Remus Posted June 5, 2012 Author Posted June 5, 2012 Hallo! Mangels Rückmeldung bin ich etwas verunsichert, ob das Problem überhaupt bei den RS-Entwicklern angekommen ist. Könnte bitte jemand kurz rückbestätigen, dass der Bug aufgenommen wurde? Oder lässt sich der Fehler nicht reproduzieren und tritt nur bei mir auf? Vielen Dank, Grüße, Jens
Livelock Posted December 19, 2012 Posted December 19, 2012 (edited) Oder lässt sich der Fehler nicht reproduzieren und tritt nur bei mir auf? Ich kann den Fehler mit der aktuellen RS Version 1.22.0.0 auf Windows 7 (SP1, 64-bit) ebenfalls reproduzieren. Damit der Fehler auftritt, muss der RS den Rechner zeitgesteuert aus dem Standby aufwecken. Sobald ich während der noch laufenden Aufnahme den Rechner aus dem Abwesenheitsmodus hole, erscheint im Logfile der Eintrag SetThreadExecutionState 0x80000000, obwohl die Aufnahme noch läuft. Mit dem folgenden Beispielablauf habe ich mich bemüht, svcdebug.log im support.zip so klein wie möglich zu machen: Zur Vorbereitung "Recording Service Stoppen", möglichst alle unnötigen Optionen ausschalten, alle Logfiles löschen 19:21 "Recording Service Starten", mit Webinterface neue Aufnahme programmieren (von 19:25 bis 20:00) 19:23 Im Startmenü "Energie sparen" aufrufen ("Sleep" auf Englisch) -> Rechner geht in den Standby 19:24 Der Rechner startet in den Abwesenheitsmodus (d.h. er macht Krach, aber der Bildschirm bleibt dunkel) 19:25 Die Aufnahme beginnt (an meinem USB-Kabeltuner leuchtet die LED) 19:26 Die Maus rumschubsen -> der Bildschirm wird eingeschaltet (im Logfile steht SetThreadExecutionState 0x80000000) 19:27 Im Startmenü "Energie sparen" aufrufen -> der Rechner geht in Standby, die Aufnahme wird abgewürgt 19:28 Den Rechner von Hand/Fuss einschalten 19:30 "Recording Service Stoppen" Viele Grüsse aus der Schweiz, Frank support.zip Edited December 19, 2012 by Livelock
Lars_MQ Posted December 21, 2012 Posted December 21, 2012 Vielen Dank für die ausführliche und sehr hilfreiche Schritt für Schritt Beschreibung. Sie war wirklich sehr hilfreich. Damit konnte ich sehr schnell das Problem einkreisen und beheben. Der Fix wird im nächsten Release drinne sein.
Recommended Posts