Jump to content

Resume playback after sleep mode/ hibernation


majstang

Recommended Posts

Have been investigating this one more than half a year wondering what may cause resuming playback fails after resume from hibernation. Cant still say for sure if it is a RS or DVBViewer bug or if it is a bug in the first place. I have made many changes to the HTPC lately as well, which makes the potential sources for errors plentyful, which makes analyzing much harder. Our user scenario is the DVBViewer is always running when HTPC gets hibernated and when waking up sometimes resuming DVBV TV playback fails. After more intense investigation I came to the conclusion that the resume failure always occurs if a RS recording timer has woken up the HTPC, then the tv channel playback never gets going. In these cases retuning the channel has to be done. If HTPC wakes up normally (by no RS recording timer) the playback resuming is always successful. This behaviour started when going from Win7 and DVBV v.4.9.6.20 to Win10 and DVBV 5.5.1 and later on DVBV 5.5.2. In the same way when going from RS 1.30.1 (where I didnt see this problem) to RS 1.31 and 1.32.

 

Resume playback after sleep mode/ hibernation is checked in the DVBV Options/General.

Link to comment

Run DVBViewer in -debug mode, so you can have a look at the WM_POWERBROADCAST events arriving after resume.

 

I guess you will only find a PBT_APMRESUMEAUTOMATIC event in the DVBViewer.log if the PC wakes up due to a recording timer, but no PBT_APMRESUMESUSPEND. Of course DBViewer is not supposed to resume playback if waking up is unattended.

Link to comment

Run DVBViewer in -debug mode, so you can have a look at the WM_POWERBROADCAST events arriving after resume.

 

I guess you will only find a PBT_APMRESUMEAUTOMATIC event in the DVBViewer.log if the PC wakes up due to a recording timer, but no PBT_APMRESUMESUSPEND.

 

Hello Griga!

 

Yes, you are right when waking up HTPC with a recording timer the PBT_APMRESUMESUSPEND is missing, hence no resume occurs.

 

Of course DBViewer is not supposed to resume playback if waking up is unattended.

 

 

But what good will that do? Is this due to energy saving purposes? The forced Windows energy savings (which is made for Laptops where it makes sense) for desktop PC:s is a menace as is already. It would be nice anyhow if DVBViewer resumes playback even if wake-up is unattended, cuz its convenient when starting up the screen the last watched channel is tuned and watchable :original:

 

Regards

majstang

Link to comment

If the PC starts in the middle of the night for a recording. The PC should not start paying loud sounds.

Aha, I see! Yes, such a case would be very disturbing. However I do think most folks out there do turn off their TV-sets during the night or working hours, so loud sounds wouldnt be a problem. How about meeting in the middle...introduce a new setting for it so people could choose how they prefer to have it or simply mute sound in case of unattended wake-up? :D

Edited by majstang
Link to comment

The reason is when turning on the TV when coming home the viewer is dead, which makes people wonder whats wrong. Now when you have explained the motivation behind not resuming playback for unattended wake-ups it makes total sense, but removing the PBT_APMRESUMESUSPEND call is not the smoothest solution to prevent loud sounds during the night. A simple mute DVBViewer sound if unattended wake-up would have been sufficient to accomplish the same IMHO.

Link to comment

If you use PC monitor, which is turned on when the PC is started it is a different situation.

 

And the DVBViewer prevents the PC from entering the standby from inactivity if video playback is on (because mostly someone is watching). If DVBViewewr playback is switched off that is not the case.

 

So if the PC is started by a different event then the recording timer. A DVBViewer playback start would prevent the PC from automatically entering standby again.

Link to comment

Well, this is not a big deal, but it's a bit annoying anyhow ;) I guess it's the inconsistensy this decision comes to that is less desirable. Playback is resumed perfectly fine in some cases and not at all in other cases, which creates confusion. I suspect this is not the only time you will have to explain and defend the behaviour.

 

There is a problem though. In my case I let the HTPC hibernate after most unattended recording timer wake-ups during the day. The always running DVBViewer doesn't resume playback for those, which I now know the reason for. However when waking up the HTPC normally (non-recording-timer), when coming home later in the day, the viewer still doesn't resume playback and that is a problem, which probably wasn't intended (or maybe it's my set-up). I don't know why the DVBViewer doesn't call PBT_APMRESUMESUSPEND in those cases. It's like if the viewer gets stuck in No Playback mode during the unattended recording timer wake-ups and can't work out what woke it up during normal wake-ups and can't resume playback from there. A channel retune is the only way to go from here.

 

If you use PC monitor, which is turned on when the PC is started it is a different situation.

 

Yes perhaps, but I assuming most folks out there are watching on their big TV-sets.

 

And the DVBViewer prevents the PC from entering the standby from inactivity if video playback is on (because mostly someone is watching). If DVBViewewr playback is switched off that is not the case.

So if the PC is started by a different event then the recording timer. A DVBViewer playback start would prevent the PC from automatically entering standby again.

 

Hmm...isn't this controlable from the RS >Web/UPnP setting>Prevent PC sleep mode triggered by users, other programs or energy settings as long as data is sent? I don't understand the logic here :blush: Maybe you meant if using a standalone DVBViewer?

Link to comment

Hmm...isn't this controlable from the RS >Web/UPnP setting>Prevent PC sleep mode triggered by users, other programs or energy settings as long as data is sent? I don't understand the logic here :blush: Maybe you meant if using a standalone DVBViewer?

No, the current RS only blocks standby if clients from other PCs in the network are assessing the RS (and that can be disabled as well). And during recordings.

 

For local access the client is responsible to block the standby though idle time out.

And the DVBViewer is doing it, every time playback is active in the DVBViewer, it is preventing standby tough idle time out. Because you have to assume someone is whining or listening to it.

Link to comment

I don't know why the DVBViewer doesn't call PBT_APMRESUMESUSPEND in those cases.

 

DVBViewer does not call PBT_APMRESUMESUSPEND. It's a message received from Windows. Please read more carefully.

 

However, basically you are right. DVBViewer picks up the last playback state after receiving PBT_APMRESUMESUSPEND. So if the last state is "playback off", e.g. after an unattended recording, DVBViewer does not resume playback. It's something I didn't consider. And to be true, it's not one of the most important things in DVBViewer / RS that have to be looked after. So maybe this issue will be handled some day or not. No promises at this point.

Link to comment

And to be true, it's not one of the most important things in DVBViewer / RS that have to be looked after. So maybe this issue will be handled some day or not. No promises at this point.

Of course, I totally agree, this is not the most important thing. My COM script to workaround this behaviour is already in place, so im in no hurry :original: Just had to vent my opinion and report my findings anyway ;)

Link to comment
×
×
  • Create New...