Jump to content

Can't hibernate while DVBViewer client running


majstang

Recommended Posts

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 by majstang
Link to comment

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!

Link to comment

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.
Link to comment

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.)

Link to comment

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?

Link to comment

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)

Link to comment

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.0

13.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 :whistle: CommandClient is much more in my taste ;)

Link to comment

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 by majstang
Link to comment

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 by majstang
Link to comment

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 by majstang
Link to comment

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.

Link to comment
  • 4 weeks later...

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. :huh:

Link to comment

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.

Link to comment

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.1

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.

 

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 by majstang
Link to comment

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?

Link to comment

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

:bye:

Edited by majstang
Link to comment

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.

:bye:

 

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

Link to comment

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 :)

:bye:

Link to comment
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 ;):D

Link to comment

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 ;):D

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 ;)

Link to comment
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) ;)

Link to comment
  • 4 weeks later...

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

Link to comment

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.

Link to comment

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 by majstang
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...