majstang Posted August 12, 2010 Share Posted August 12, 2010 (edited) I did just found a REALLY nasty bug! I updated to Recording Service 1.6.2.0 Beta yesterday evening. Before this no problems hibernating while DVBViewer 4.2.1 Client was running. When I woke up this morning i did noticed HTPC didnt hibernate last night and had no time to investigate why. I can now conclude hibernating while running DVBViewer RS Client 4.2.1 is impossible...exactly like the problem with DVBViewer beta.165. When stopping Recording Service and start up DVBViewer 4.2.1 using tuners directly (no unicast) hibernating works perfect while DVBViewer is running. Conclusion...there is a nasty one in the new Recording Service. Edited August 12, 2010 by majstang Quote Link to comment
desweil Posted August 12, 2010 Share Posted August 12, 2010 standby never really worked well, when DVBViewer wasn't closed. Thats what I found out and I think most of the other forum posts say the same thing. FOr me a Stop graph solves the problem. I can then go into stadnby with open DVBViewer. Before that I always closed DVBViewer and restarted it after resume, because SOMETIMES the recording service couldn't shut down after recording becvause DVBViewer prevented it! Quote Link to comment
majstang Posted August 12, 2010 Author Share Posted August 12, 2010 standby never really worked well, when DVBViewer wasn't closed. Thats what I found out and I think most of the other forum posts say the same thing. FOr me a Stop graph solves the problem. I can then go into stadnby with open DVBViewer.I don't exactly follow you, what do you mean with Stop Graph? When a hibernate call is made the graph closes per automatic and Rebuild Graph and Close Graph options in View menu becomes inactive. Yes, I agree standby/hibernate has not worked well when DVBViewer wasnt closed some time ago, but the most severe issues were fixed from v.4.0. Now what's left is the issue with DVBViewer not behaving as other players do when a hibernation/standby are being intercepted and I suspect this is the issue developers are struggling with which could explain the issues we are seeing now. Also only users with Windows XP should be affected. Quote Link to comment
majstang Posted August 12, 2010 Author Share Posted August 12, 2010 Downgrading back to Recording Service 1.6.0.6 fixes the problem. It is now possible to hibernate when client (v.4.2.1) is running again. Quote Link to comment
desweil Posted August 13, 2010 Share Posted August 13, 2010 for me that never really worked. Sometimes the recording service wanted to hibernate with DVBViewer running. What happened was that the graph was stopped but the PC wasn't going into hibernate. in eventlog you could see that DVBViewer prevented it. There is a huge thread here in the forum where this issue was discussed and in the end the solution was, to not open DVBViewer when recording service autoatically resumes.(wiht evenghost makros etc.) Quote Link to comment
majstang Posted August 13, 2010 Author Share Posted August 13, 2010 For me hibernation and resuming has worked really well since v.4.0. Ok, thanks for this information! Being forced to use these kind of workarounds sounds really horrible. Standby/hibernate functions MUST work flawless and if not it should be highly prioritized finding a working solution. A major point with a HTPC is to be abled to use it as we have used our TV-sets earlier...TV is on all the time. Anything else is unacceptable. @Desweil...do you use Windows XP? Quote Link to comment
desweil Posted August 13, 2010 Share Posted August 13, 2010 Yes I use XP. I think standby resume did work when being activated via the remote control. The problem was the after recording action of the rec service. The "go into standby" function didn't always work when DVBViewer was running! Which is logical because DVBViewer is meant to prevent shutdown/standby when it is running(as long as the exit button in DVBViewer wasn't pressed. Then the configurable action happens, which could be standby). I never got a explanation from the developers HOW a Rec. Service installation with local DVBViewer should be set up, when it is meant to work like a STB(PC on, tv is shown in FUllscreen, switch off for standby) Quote Link to comment
desweil Posted August 13, 2010 Share Posted August 13, 2010 here is the old thread http://www.DVBViewer.tv/forum/topic/35312-kein-standby-nach-aufnahme/page__hl__%2Brecording+%2Bservice+%2Bshutdown Quote Link to comment
majstang Posted August 13, 2010 Author Share Posted August 13, 2010 Yes, you seem to be right! That thread covers this issue. Did some checking in the svcdebug.log and this is the difference between RS v.1.6.2.0 and v.1.6.0.6 with same config settings: RS v.1.6.2.013.08.10 00:06:00.312 TRecording Release FireDTV BDA Tuner DVBC (1) 13.08.10 00:06:00.312 TRecording Destroy FireDTV BDA Tuner DVBC (1) 13.08.10 00:06:00.609 CreateProcessW 4176 13.08.10 00:06:00.906 ReleaseStandbyblock TRecording 13.08.10 00:06:00.906 SetThreadExecutionState 0x80000000 13.08.10 00:06:00.906 Releasereference TRecording: 0 13.08.10 00:06:00.921 Process Params 13.08.10 00:06:01.359 Proctimer started 13.08.10 00:06:01.359 SetThreadExecutionState 0x80000041 13.08.10 00:06:01.359 SetStandbyblock TProcessTimer 13.08.10 00:06:01.359 AddReference TProcessTimer: 1 13.08.10 00:06:01.421 AddReference webserver: 2 13.08.10 00:06:01.718 QueryStandby Denied RS v.1.6.0.6 13.08.10 00:32:35.171 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 13.08.10 00:32:35.171 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 13.08.10 00:32:35.281 ReleaseStandbyblock CmdClientDisconnect 13.08.10 00:32:35.281 SetThreadExecutionState 0x80000000 13.08.10 00:32:35.281 Releasereference CmdClientDisconnect: 0 13.08.10 00:32:35.281 TUniCastServer Disconnect: 10054 13.08.10 00:32:35.281 QueryStandby Granted 13.08.10 00:32:35.328 Standby PBT_APMSUSPEND 13.08.10 00:32:35.328 Setting next recording: 2010-08-13 05:01:00 13.08.10 00:32:35.328 ThdProc Enter Don't like that TRecording thingie at all CommandClient is much more in my taste Quote Link to comment
majstang Posted August 21, 2010 Author Share Posted August 21, 2010 (edited) I see people have reported about this bug in the DVBViewer beta.175/Recording Service 1.6.2.0 in the German threads as well. I therefor did some tests and wanna report the full recording service debuglog for em. Hope that could be to any help fixing this. These are the steps made. All tests were done with two unicastdevices and same settings in both DVBV and RS: 1) Initiated a hibernation with DVBViewer 4.2.1 and RS v.1.6.0.6 running----> hibernation successful 2) Initiated a hibernation twice with DVBViewer beta.175 and RS v.1.6.0.6 running----> hibernation denied both tries 3) Initiated a hibernation with DVBViewer 4.2.1 and RS v.1.6.2.0 running----> hibernation denied 4) Initiated a hibernation twice with DVBViewer beta.175 and RS v.1.6.2.0 running----> hibernation denied both tries 21.08.10 21:04:06.828 Start App ----------------------------------- 21.08.10 21:04:06.828 thread service started 21.08.10 21:04:06.843 StartService start timer 21.08.10 21:04:06.843 StartService create plugin list 21.08.10 21:04:07.046 StartService loadchannellist 21.08.10 21:04:07.062 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (1) 21.08.10 21:04:07.062 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (2) 21.08.10 21:04:07.062 Device Check present 21.08.10 21:04:07.062 CheckDevicespresent start 21.08.10 21:04:07.078 loadsetup load vcr 21.08.10 21:04:07.109 StartService load setup 21.08.10 21:04:07.109 Recorderservice Enabled 21.08.10 21:04:55.109 SetThreadExecutionState 0x80000041 21.08.10 21:04:55.109 SetStandbyblock CMDClientConnect 21.08.10 21:04:55.109 AddReference CMDClientConnect: 1 21.08.10 21:04:55.109 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 546000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4403, VideoPID: 4147, PMT: 307, SID: 1155, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:04:55.218 Opendevice FireDTV 21.08.10 21:04:55.343 Whole transponder True 21.08.10 21:04:55.343 TUCCommandClient Allocate FireDTV BDA Tuner DVBC (1) 21.08.10 21:04:55.640 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:04:55.640 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:04:55.656 TUCCommandClient Addpid: 18 21.08.10 21:04:55.718 TUCCommandClient Addpid: 4147 4403 0 307 7987 21.08.10 21:04:56.125 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:04:59.109 TUCCommandClient Addpid: 1 21.08.10 21:05:20.515 TUCCommandClient DelPid: 7987 21.08.10 21:05:20.578 TUCCommandClient DelPid: 18 4147 4403 0 307 1 21.08.10 21:05:20.593 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 21.08.10 21:05:20.593 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 21.08.10 21:05:20.687 ReleaseStandbyblock CmdClientDisconnect 21.08.10 21:05:20.687 SetThreadExecutionState 0x80000000 21.08.10 21:05:20.687 Releasereference CmdClientDisconnect: 0 21.08.10 21:05:29.859 QueryStandby Granted 21.08.10 21:05:30.031 Standby PBT_APMSUSPEND 21.08.10 21:05:30.031 Setting next recording: 2010-08-22 11:42:00 21.08.10 21:05:30.031 ThdProc Enter 21.08.10 21:06:22.953 Time changed 21.08.10 21:06:28.812 Resume PBT_APMRESUMESUSPEND 21.08.10 21:06:28.812 ReleaseStandbyblock PBT_APMRESUMESUSPEND 21.08.10 21:06:28.812 SetThreadExecutionState 0x80000000 21.08.10 21:06:28.812 Killtimer Dispose WT 21.08.10 21:06:28.812 Killtimer close thread 21.08.10 21:06:28.812 fwakeup 0 21.08.10 21:06:28.812 Device Check present 21.08.10 21:06:28.828 CheckDevicespresent start 21.08.10 21:06:28.828 fwakeup do 21.08.10 21:06:28.828 Reset start 21.08.10 21:06:31.953 Reset \\?\avc#digital_everywhere&firedtv_c#ci&typ_5&id_0#4f25000226871200#{71985f48-1ca1-11d3-9cc8-00c04f7971e0}\{db365890-165f-11d0-a195-0020afd156e4} True 21.08.10 21:06:34.109 Reset \\?\avc#digital_everywhere&firedtv_c#ci&typ_5&id_0#d111000226871200#{71985f48-1ca1-11d3-9cc8-00c04f7971e0}\{db365890-165f-11d0-a195-0020afd156e4} True 21.08.10 21:06:34.125 NextEPGUpdate 1899-12-29 21.08.10 21:06:34.125 Resume PBT_APMRESUMEAUTOMATIC 21.08.10 21:06:34.125 ReleaseStandbyblock PBT_APMRESUMESUSPEND 21.08.10 21:06:34.125 SetThreadExecutionState 0x80000000 21.08.10 21:06:34.125 fwakeup -1 21.08.10 21:06:34.125 SetThreadExecutionState 0x80000041 21.08.10 21:06:34.125 SetStandbyblock CMDClientConnect 21.08.10 21:06:34.125 AddReference CMDClientConnect: 1 21.08.10 21:06:34.140 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 546000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4403, VideoPID: 4147, PMT: 307, SID: 1155, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:06:34.625 Opendevice FireDTV 21.08.10 21:06:34.843 Whole transponder True 21.08.10 21:06:34.843 TUCCommandClient Allocate FireDTV BDA Tuner DVBC (1) 21.08.10 21:06:35.156 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:06:35.156 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:06:35.156 TUCCommandClient Addpid: 4147 4403 0 307 7987 21.08.10 21:06:35.234 TUCCommandClient Addpid: 1 21.08.10 21:06:35.796 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:06:45.828 TUCCommandClient DelPid: 7987 21.08.10 21:06:45.828 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 482000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4358, VideoPID: 4102, PMT: 262, SID: 1097, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:06:46.140 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:06:46.140 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:06:46.140 TUCCommandClient Addpid: 18 21.08.10 21:06:46.140 TUCCommandClient Addpid: 4102 4358 262 7942 21.08.10 21:06:46.140 TUCCommandClient Addpid: 4614 21.08.10 21:06:46.343 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:06:51.156 TUCCommandClient DelPid: 4147 4403 0 307 1 18 4102 4358 262 7942 4614 21.08.10 21:06:51.156 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 21.08.10 21:06:51.156 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 21.08.10 21:06:51.265 ReleaseStandbyblock CmdClientDisconnect 21.08.10 21:06:51.265 SetThreadExecutionState 0x80000000 21.08.10 21:06:51.265 Releasereference CmdClientDisconnect: 0 21.08.10 21:07:03.390 SetThreadExecutionState 0x80000041 21.08.10 21:07:03.390 SetStandbyblock CMDClientConnect 21.08.10 21:07:03.390 AddReference CMDClientConnect: 1 21.08.10 21:07:03.390 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 482000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4358, VideoPID: 4102, PMT: 262, SID: 1097, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:07:03.421 Opendevice FireDTV 21.08.10 21:07:03.546 Whole transponder True 21.08.10 21:07:03.546 TUCCommandClient Allocate FireDTV BDA Tuner DVBC (1) 21.08.10 21:07:03.859 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:07:03.859 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:07:03.859 TUCCommandClient Addpid: 18 21.08.10 21:07:03.890 TUCCommandClient Addpid: 4102 4358 0 262 7942 21.08.10 21:07:04.062 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:07:05.062 TUCCommandClient Addpid: 1 21.08.10 21:07:05.578 TUCCommandClient Addpid: 4614 21.08.10 21:07:19.093 QueryStandby Denied 21.08.10 21:07:43.984 QueryStandby Denied 21.08.10 21:07:46.937 TUCCommandClient DelPid: 7942 21.08.10 21:07:47.093 TUCCommandClient DelPid: 18 4102 4358 0 262 1 4614 21.08.10 21:07:47.093 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 21.08.10 21:07:47.093 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 21.08.10 21:07:47.203 ReleaseStandbyblock CmdClientDisconnect 21.08.10 21:07:47.203 SetThreadExecutionState 0x80000000 21.08.10 21:07:47.203 Releasereference CmdClientDisconnect: 0 21.08.10 21:08:09.281 StopService start stopping service 21.08.10 21:08:09.296 TUniCastServer Stop Server 21.08.10 21:08:09.343 savesetup save vcr 21.08.10 21:08:09.343 Stop ClearDeviceList 21.08.10 21:08:09.343 Stop Done ClearDeviceList 21.08.10 21:08:09.343 Stop Unload settings 21.08.10 21:08:09.421 Stop Couninitialize 21.08.10 21:08:09.437 Recorderservice Disabled 21.08.10 21:08:09.437 StopService stop service 21.08.10 21:08:09.437 Execute setrunning false 21.08.10 21:08:09.437 Execute release shared 21.08.10 21:08:09.437 Execute Couninitialize 21.08.10 21:08:09.437 thread service ended 21.08.10 21:08:09.437 TUniCastServer Stop Server 21.08.10 21:08:09.437 TUniCastServer Stop Server 21.08.10 21:08:09.968 End App ----------------------------------- 21.08.10 21:08:27.640 Start App ----------------------------------- 21.08.10 21:08:27.640 thread service started 21.08.10 21:08:27.656 StartService start timer 21.08.10 21:08:27.656 StartService create plugin list 21.08.10 21:08:27.875 StartService loadchannellist 21.08.10 21:08:27.875 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (1) 21.08.10 21:08:27.875 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (2) 21.08.10 21:08:27.875 Device Check present 21.08.10 21:08:27.875 CheckDevicespresent start 21.08.10 21:08:27.875 CheckDevicespresent end 21.08.10 21:08:27.875 Start Searches load 21.08.10 21:08:27.875 Start Tasks load 21.08.10 21:08:27.890 Start VCR load 21.08.10 21:08:27.906 Start EPG load 21.08.10 21:08:27.906 loadsetup load vcr 21.08.10 21:08:27.921 StartService load setup 21.08.10 21:08:27.921 Recorderservice Enabled 21.08.10 21:08:32.250 StopService start stopping service 21.08.10 21:08:32.250 TUniCastServer Stop Server 21.08.10 21:08:32.296 savesetup save vcr 21.08.10 21:08:32.296 Stop ClearDeviceList 21.08.10 21:08:32.296 Stop Done ClearDeviceList 21.08.10 21:08:32.296 Stop Unload settings 21.08.10 21:08:32.312 Stop Couninitialize 21.08.10 21:08:32.328 Recorderservice Disabled 21.08.10 21:08:32.328 StopService stop service 21.08.10 21:08:32.328 Execute setrunning false 21.08.10 21:08:32.328 Execute release shared 21.08.10 21:08:32.328 Execute Couninitialize 21.08.10 21:08:32.328 thread service ended 21.08.10 21:08:32.328 TUniCastServer Stop Server 21.08.10 21:08:32.328 TUniCastServer Stop Server 21.08.10 21:08:32.328 End App ----------------------------------- 21.08.10 21:08:51.453 Start App ----------------------------------- 21.08.10 21:08:51.453 thread service started 21.08.10 21:08:51.468 StartService start timer 21.08.10 21:08:51.468 StartService create plugin list 21.08.10 21:08:51.703 StartService loadchannellist 21.08.10 21:08:51.703 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (1) 21.08.10 21:08:51.703 TDVBDevice.InitDevice FireDTV BDA Tuner DVBC (2) 21.08.10 21:08:51.703 Device Check present 21.08.10 21:08:51.703 CheckDevicespresent start 21.08.10 21:08:51.703 CheckDevicespresent end 21.08.10 21:08:51.703 Start Searches load 21.08.10 21:08:51.703 Start Tasks load 21.08.10 21:08:51.718 Start VCR load 21.08.10 21:08:51.734 Start EPG load 21.08.10 21:08:51.734 loadsetup load vcr 21.08.10 21:08:51.734 StartService load setup 21.08.10 21:08:51.734 Recorderservice Enabled 21.08.10 21:08:59.078 SetThreadExecutionState 0x80000041 21.08.10 21:08:59.078 SetStandbyblock webserver 21.08.10 21:08:59.078 AddReference webserver: 1 21.08.10 21:08:59.234 AddReference CMDClientConnect: 2 21.08.10 21:08:59.234 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 482000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4358, VideoPID: 4102, PMT: 262, SID: 1097, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:08:59.296 Opendevice FireDTV 21.08.10 21:08:59.421 Whole transponder True 21.08.10 21:08:59.421 TUCCommandClient Allocate FireDTV BDA Tuner DVBC (1) 21.08.10 21:08:59.718 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:08:59.718 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:08:59.718 TUCCommandClient Addpid: 18 21.08.10 21:08:59.734 TUCCommandClient Addpid: 4102 4358 0 262 7942 21.08.10 21:09:00.093 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:09:00.875 TUCCommandClient Addpid: 1 21.08.10 21:09:00.875 TUCCommandClient Addpid: 4614 21.08.10 21:09:12.000 TUCCommandClient DelPid: 7942 21.08.10 21:09:12.046 TUCCommandClient DelPid: 18 4102 4358 0 262 1 4614 21.08.10 21:09:12.046 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 21.08.10 21:09:12.046 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 21.08.10 21:09:12.156 Releasereference CmdClientDisconnect: 1 21.08.10 21:09:15.921 QueryStandby Denied 21.08.10 21:09:47.265 ReleaseStandbyblock webserver 21.08.10 21:09:47.265 SetThreadExecutionState 0x80000000 21.08.10 21:09:47.265 Releasereference webserver: 0 21.08.10 21:09:50.875 SetThreadExecutionState 0x80000041 21.08.10 21:09:50.875 SetStandbyblock CMDClientConnect 21.08.10 21:09:50.875 AddReference CMDClientConnect: 1 21.08.10 21:09:50.875 TUCCommandClient Set Tuner Tunertype: 0, Frequency: 482000, Symbolrate: 6875, LNB: 0, Selection: 0, Polarity: 3, DiseqC: 3, FEC: 0, AudioPID: 4358, VideoPID: 4102, PMT: 262, SID: 1097, SatModulation: 0, DiseqCValue: 0, NID: 40999, Flags: 25 21.08.10 21:09:50.921 Opendevice FireDTV 21.08.10 21:09:51.046 Whole transponder True 21.08.10 21:09:51.046 TUCCommandClient Allocate FireDTV BDA Tuner DVBC (1) 21.08.10 21:09:51.343 TBDACIFireDTVModule CI Base SetTuner Entering 21.08.10 21:09:51.343 TBDACIFireDTVModule CI Base SetTuner Leaving 21.08.10 21:09:51.343 TUCCommandClient Addpid: 18 21.08.10 21:09:51.359 TUCCommandClient Addpid: 4102 4358 0 262 7942 21.08.10 21:09:51.484 TBDACIFireDTVModule WinProc Received PMT ready 21.08.10 21:09:52.468 TUCCommandClient Addpid: 1 21.08.10 21:09:52.890 TUCCommandClient Addpid: 4614 21.08.10 21:09:52.921 AddReference webserver: 2 21.08.10 21:10:05.796 QueryStandby Denied 21.08.10 21:10:19.218 QueryStandby Denied 21.08.10 21:10:23.265 TUCCommandClient DelPid: 7942 21.08.10 21:10:23.421 TUCCommandClient DelPid: 18 4102 4358 0 262 1 4614 21.08.10 21:10:23.421 TUCCommandClient Release FireDTV BDA Tuner DVBC (1) 21.08.10 21:10:23.421 TUCCommandClient Destroy FireDTV BDA Tuner DVBC (1) 21.08.10 21:10:23.531 Releasereference CmdClientDisconnect: 1 21.08.10 21:10:23.921 ReleaseStandbyblock webserver 21.08.10 21:10:23.921 SetThreadExecutionState 0x80000000 21.08.10 21:10:23.921 Releasereference webserver: 0 Edited August 21, 2010 by majstang Quote Link to comment
majstang Posted August 22, 2010 Author Share Posted August 22, 2010 (edited) New RS version 1.6.2.1 came close to fix this issue, but not home yet. Add: Configuration program - Web/UPnP settings: Now you can enable/disable the blocking of Standby/Hibernate for the Web (and UPnP Streaming) Server and for the UPnP web server. When unchecking this box in configuration window, it fixes the problem with not being abled to hibernate HTPC while DVBViewer 4.2.1 is running with RS version 1.6.2.1. It now works as it should. HOWEVER, still problem to do the same with DVBViewer beta.175. HTPC will NOT hibernate (still denied) if DVBV beta.175 and RS 1.6.2.1 is running simultainously. Edited August 22, 2010 by majstang Quote Link to comment
majstang Posted August 24, 2010 Author Share Posted August 24, 2010 (edited) Seems Im the only one left not being abled to hibernate while DVBV beta.177 is running with RS 1.6.2.1 now since this was added: Add: Configuration program - Web/UPnP settings: Now you can enable/disable the blocking of Standby/Hibernate for the Web (and UPnP Streaming) Server and for the UPnP web server. I have this box unchecked for the webserver. All posting about folks not being abled to standby/hibernate has stopped. I am abled to hibernate with DVBV 4.2.1 and RS 1.6.2.1. Is this some issue that has been confirmed in the testbench? DVBV beta.177 or RS 1.6.2.1 (i dont know which) is even blocking/denying shutdown/restart as long as the client is running. Would it make any difference for you to solve this case if I post support.zip, debug logs and give up informations such as im not using the UPnP server and having the Google Chrome browser? What should i do when RS still denies hibernation despite the block box is unchecked. Is there some setting that could have any effect on this? I have been testing everything i could think of without any success so far. What concerns me is it would not be funny at all being the only one stuck with DVBViewer 4.2.1 when the 4.5 will be released if this in not fixed Edited August 24, 2010 by majstang Quote Link to comment
majstang Posted August 24, 2010 Author Share Posted August 24, 2010 Forgot to point out this issue is WinXP specific ONLY! When testing hibernating while DVBV beta.177 and RS 1.6.2.1 (with block box unchecked) is running on my Windows 7 x86 system with exactly the same hardware things goes as they should and no problem what so ever. Quote Link to comment
majstang Posted September 18, 2010 Author Share Posted September 18, 2010 As expected the DVBViewer 4.5 RC1 did not make a difference regarding this issue, since the problem lies somewhere in Recording Service. Hibernation with DVBViewer running works just fine as long as not using any unicast devices. What I dont understand is what makes RS deny me hibernation despite Block hibenationbox is unchecked when DVBViewer is runned as a client (unicast devices)?? Looking forward to next RS version dealing with this problem cuz it is a pain in the neck not being abled to use the new versions unattended because of this bug. Quote Link to comment
raty Posted September 23, 2010 Share Posted September 23, 2010 You appear to have a different requirement for the sleep/hibernation of these systems. I find that this now works for me as my system is setup to go to sleep after 5 minutes. All the time I am watching a video source or listerning to music my system stays running which is what I expect. Once I stop DVBViewer (power off on the remote) my system sleeps as expected. I expect some other part of the recording service needs a switch on it to allow it to perform in a manner that you require. Quote Link to comment
majstang Posted September 23, 2010 Author Share Posted September 23, 2010 (edited) I expect some other part of the recording service needs a switch on it to allow it to perform in a manner that you require. But Lars introduced this switch you are talking about in RS 1.6.2.1Add: Configuration program - Web/UPnP settings: Now you can enable/disable the blocking of Standby/Hibernate for the Web (and UPnP Streaming) Server and for the UPnP web server. You appear to have a different requirement for the sleep/hibernation of these systems. Not in particular! ALL Software running on a MS system should handle standbyquery flawless. It is therefor hard to accept this WindowsXP specific bug which makes it impossible to hibernate the system when DVBViewer is running. Despite this box/switch being empty the freaking RS is still blocking Standby/hibernation on XP when DVBV is running. This has been the case since I reported about this other bug: http://www.DVBViewer.tv/forum/topic/41323-onmessage-intercepting-hibernation-trouble/ The changes developers made after this report in DVBV beta.165 was the first time i wasnt abled to hibernate when DVBV is running. Last working version was in other words beta.160. This issue does not exist on my Windows7 system only on XP. I dont know if the issue is in Recording Service or in DVBViewer betas. I think it is in RS cuz RS is the one blocking the standbyquery and how this is even possible with Standby/Hibernate blocking disabled in RS beats me. Cant debug this on my own either without the source code. Can only hope Lars finds the cause of this issue later on. If not im stuck with DVBV 4.2.1 Edited September 23, 2010 by majstang Quote Link to comment
majstang Posted September 26, 2010 Author Share Posted September 26, 2010 I probably dont need to fill in anything else on this: DVBViewer 4.5 RC1 26.09.10 17:13:00.578 Gotstr SIG 100 26.09.10 17:13:10.859 Gotstr SIG 100 26.09.10 17:13:18.500 Powermessage PBT_APMQUERYSTANDBY 26.09.10 17:13:21.171 Gotstr SIG 100 26.09.10 17:13:31.515 Gotstr SIG 100 26.09.10 17:13:41.843 Gotstr SIG 100 RS 1.6.5.1 26.09.10 17:13:18.515 QueryStandby Denied Unless the developers has any ideas on how I could solve the issue. Do you think the reason DVBViewer 4.5 RC1/RS blocks hibernation while running is DVBV software related or not? If not why can i hibernate while DVBV 4.2.1 is running as client? Quote Link to comment
majstang Posted September 26, 2010 Author Share Posted September 26, 2010 (edited) Hi Lars_MQ! Sorry for bumping again! Did some more testing and came to the conclusion the graph is the culprit regarding this issue...or more precise the concept you chose for DVBViewer to not close the graph immediatly when receiving powermessage PBT_APMQUERYSTANDBY. This solution blocks the PBT_APMSTANDBY. RS denies hibernation as long as the graph in client is up. When closing the graph in the client DVBV 4.5 RC1 (client is still running) and then hibernate all goes well with no problem at all. That is also why the DVBV 4.2.1 is working, cuz it instantly closes the graph when receiving powermessage PBT_APMQUERYSTANDBY. Could it be a timings problem maybe? DVBViewer doesnt get enough time to receive and act upon the PBT_APMQUERYSTANDBY, cuz by then RS has already denied the standbyquery and cancels out the PBT_APMSTANDBY reception for DVBV. I did notice in the log in the post above it takes 15 milliseconds from DVBViewer logs the PBT_APMQUERYSTANDBY to RS denies the standbyquery. It is a very short timeframe and if you could consider making an attempt to prolong/delay this timeframe could be the answer to get things working between DVBV betas and RS. Sounds to be the logic explanation to me. What say you? As usual I wont expect any answers since i havent got one so far about this issue. majstang Edited September 26, 2010 by majstang Quote Link to comment
majstang Posted September 27, 2010 Author Share Posted September 27, 2010 Wanna show you the log when hibernating while DVBV 4.5 RC1 client is running, but with closed graph. Only for comparison reasons when hibernation goes well. Now when DVBV 4.5 RC1 receives the PBT_APMQUERYSTANDBY it takes 47 milliseconds before RS decides to grant the QueryStandby. Quite a big difference when comparing with the 15 milliseconds it took for RS to deny hibernation when graph was still playing in DVBV when hibernation was requested in the earlier example. One last thing. If there is no solution for this issue i would be ever thankful if you could consider going back to the old graph close when receiving PBT_APMQUERYSTANDBY ala DVBV 4.2.1 style, before releasing the DVBV 4.5 Pro. It is much easier to live with a graph closing when hibernating compared to hibernation not working at all when client is running. DVBV 4.5 RC1 client 26.09.10 19:43:26.343 Powermessage PBT_APMQUERYSTANDBY 26.09.10 19:43:26.453 TCMDSocketThread Sessionstarted 26.09.10 19:43:26.468 Gotstr OK. 26.09.10 19:43:26.468 Sendstr UNSETTUNER 0 482000 6875 0 0 3 3 0 4359 4103 263 1098 0 0 0 25 0 45 40999 26.09.10 19:43:26.468 Sendstr DELPID 4103 4359 0 263 7942 26.09.10 19:43:26.515 TfrmMain Release Unicast Network Device 26.09.10 19:43:26.515 TfrmMain Destroy Unicast Network Device 26.09.10 19:43:26.515 Sendstr DELPID 18 26.09.10 19:43:26.515 TUCStreamThread Sessionended 26.09.10 19:43:26.515 TWSocketThread Sessionended 26.09.10 19:43:26.515 TfrmMain Destroyed Unicast Network Device 26.09.10 19:43:26.515 Powermessage PBT_APMSTANDBY RS 1.6.5.1 26.09.10 19:43:26.390 QueryStandby Granted 26.09.10 19:43:26.468 SetStandbyblock CMDClientConnect 26.09.10 19:43:26.468 SetThreadExecutionState 0x80000041 26.09.10 19:43:26.468 AddReference CMDClientConnect: 1 26.09.10 19:43:26.515 ReleaseStandbyblock CmdClientDisconnect 26.09.10 19:43:26.515 SetThreadExecutionState 0x80000000 26.09.10 19:43:26.515 Releasereference CmdClientDisconnect: 0 26.09.10 19:43:26.609 Standby PBT_APMSUSPEND 26.09.10 19:43:26.609 Setting next recording: 2010-09-26 19:56:00 26.09.10 19:43:26.609 ThdProc Enter Quote Link to comment
majstang Posted September 29, 2010 Author Share Posted September 29, 2010 Thanks Lars for going back to the DVBV 4.2.1 handling of powermessage PBT_APMQUERYSTANDBY. Now hibernation while DVBV 4.5 RC2 client is running works again. Two ways to interpret this decision: 1. There is simply no solution to get this working (which I doubt). 2. There is simply no more time for dealing with this kind of timeconsuming stuff when the official 4.5 release is getting very close. Time spent on other more important bugs is better spent time. Nevertheless the prematurely closing of the graph seem to be the answer to get hibernation working, for now. Sadly i have to live with the graph being closed when i do block/intercept/cancel hibernation with my "intercept hibernationscript", but it is a small thing compared to not being abled to hibernate at all. Hopefully i can have accurate WindowsXP VM_POWERBROADCAST handling as a long-term request...when it is time to initiate next betaproject, maybe you guys could dig out a really neat solution? Thanks for your efforts so far Quote Link to comment
Lars_MQ Posted September 29, 2010 Share Posted September 29, 2010 1. There is simply no solution to get this working (which I doubt).2. There is simply no more time for dealing with this kind of timeconsuming stuff when the official 4.5 release is getting very close. Time spent on other more important bugs is better spent time. Actually, first this only matters for windows < Vista and the second reason: I changed it because of a user complaint and I simply can't remember what it was about, so I just reverted it back and now I wait for the complaint again and ask him/her to discuss it with you, problem solved for me Quote Link to comment
majstang Posted September 29, 2010 Author Share Posted September 29, 2010 Actually, first this only matters for windows < Vista and the second reason: I changed it because of a user complaint and I simply can't remember what it was about, so I just reverted it back and now I wait for the complaint again and ask him/her to discuss it with you, problem solved for me Actually, i dont think discussing this problem with a fellow XP user wont solve anything, but if you give me the source code and I will fix this problem for you Quote Link to comment
Lars_MQ Posted September 29, 2010 Share Posted September 29, 2010 i dont think discussing this problem with a fellow XP user wont solve anything Of course it will. It will keep (both of) you off my back. I call that a solution. Oh btw. I highly doubt the source code would help you. That's one big ugly und complex thing. But to be honest it will solve itself in time (byebye xp) Quote Link to comment
majstang Posted September 29, 2010 Author Share Posted September 29, 2010 man you're simply too much Quote Link to comment
mr_5a Posted October 24, 2010 Share Posted October 24, 2010 Hi I'm a new user. Windows 7 with UAC. Brand new PC - I installed DVBViewer 4.5.0.0 - Standby/Hibernate worked for me very well. On the same PC I installed last Recording service, 1.6.5.2beta. I created Unicast devices. I ticked off all standby blocking features both in DVBViewer and Recording service (incl. DVBServer). I don't have anything in Timer. - Standby/Hibernate stops working. I get screens off, but the PC remains running. I cannot even initiate standby from windows. DVBViewer blocks it. With stopped graph standby works OK. Likely unicast devices are the problem. Peter Quote Link to comment
Tjod Posted October 24, 2010 Share Posted October 24, 2010 There are tow possibility's: 1. Use the standby command inside the DVBViewer (e.g. OSD-Menu > System > Standby; DVBViewer.exe -x12324) 2. Or if you have to use a external standby command, you have at lest stop the graph first. Quote Link to comment
majstang Posted October 24, 2010 Author Share Posted October 24, 2010 (edited) Hi I'm a new user. Windows 7 with UAC. Brand new PC - I installed DVBViewer 4.5.0.0 - Standby/Hibernate worked for me very well. On the same PC I installed last Recording service, 1.6.5.2beta. I created Unicast devices. I ticked off all standby blocking features both in DVBViewer and Recording service (incl. DVBServer). I don't have anything in Timer. - Standby/Hibernate stops working. I get screens off, but the PC remains running. I cannot even initiate standby from windows. DVBViewer blocks it. With stopped graph standby works OK. Likely unicast devices are the problem. Peter Hi Peter! This issue of yours has nothing to do with this topic, cuz this topic is all about Windows XP hibernation troubles in combination with DVBViewer and Rec.Service. Since you are using Win7 they have nothing in common. Quite intresting though you have managed to accomplish something that nobody has succeeded with before...blocking standby/hibernation on Win7. Microsoft removed that feature from Vista and forward. There must be something seriously wrong with your PC, cuz DVBViewer and recording service per say could not bring such an issue on a Win7 system. Edited October 24, 2010 by majstang Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.