Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So I'm a big fan of the way JRiver prevents the computer from sleeping (or the monitor from turning off, or the screen saver from engaging) when playing music, but I've run into some trouble with the behavior lately.  A few months ago I started using Gizmo, and I've also been having trouble getting my computer to sleep or engage the screensaver lately. I think the behavior is related.

Here are the testing steps I've done so far:

1) I tried setting the PC to sleep, turn off the monitor, or engage the screensaver after 1 minute so I could test different items, and see what was keeping it up.  After going through powercfg and a few other things, it seemed to be linked to incoming LAN traffic.  So I decided to investigate Gizmo, and here's what I found: if any mobile device in my house has an instance of gizmo running in the background (which most of my devices constantly do because android rarely seems to kill a process) the PC will not sleep, turn off the monitor, or engage the screen saver, even when nothing is playing.  I made sure that no devices were actively using Gizmo (i.e. that they'd exited the interface so Gizmo should have been "hibernating"), but that made no difference.  

2) Force stopping Gizmo on all devices (or taking all of the devices out of wi-fi range of the house) resulted in the computer almost instantly going to sleep/turning off the monitor/ or engaging the screensaver.  It didn't seem to matter how long I waited; if a device had opened Gizmo at some point and remained within wifi range, it would keep the pc awake hours after the last interaction with Gizmo, or in the case of my wife's tablet (a galaxy note 10), more than a day since she'd last used Gizmo!  Killing all Gizmo instances solved the issue completely (until someone opened gizmo again).

So the effect of this is that my main server HTPC doesn't have a working screen saver/sleep mode, and the only way I've found to solve it is to force stop Gizmo on several devices, which has a pretty low wife acceptance factor.  Is there something in Gizmo's settings (or maybe in android device settings) that might help with this (some kind of "close out if idle" setting)?  I like that Gizmo can wake the PC with a magic packet and keep it awake, I just don't know how to keep it from keeping the PC "up all night" and/or burning out my LED monitor.  For now I just turn off my HTPC when I'm not in the room, but not having the server available isn't ideal.

Any advice would be appreciated as I'm relatively new to the Gizmo side of media network.

[Hendrik]

You can check inside MC if its keeping the PC awake, or if its something Windows does based solely on Network traffic - that would help already to identify the problem.
The Information is in Help -> System Info, it has a Power section that lists all events and their expiry time which would take a system alive.

If its just based on Network traffic, that might become more tricky, but we'll get to that when we have to.

[mwillems]

You can check inside MC if its keeping the PC awake, or if its something Windows does based on Network traffic - that would help already to identify the problem.
The Information is in Help -> System Info, it has a Power section that lists all events and their expiry time which would take a system alive.

If its just based on Network traffic, that might become more tricky, but we'll get to that when we have to.

Thanks, I'd forgotten that was in the system info.  I'll test that tonight when I get home. 

[JimH]

Make sure Gizmo is the latest from the Play Store.

[mwillems]

Make sure Gizmo is the latest from the Play Store.

Ok, did some testing.  I have the current version of Gizmo.  The system info dialog shows "no entries that affect current power state," but it still won't sleep or turn on the screen saver.  My wife's tablet seems to the main offender; when I force stopped Gizmo on her tablet (or turned off the tablet entirely) sleep worked.  I'll keep chewing on this and see if I can figure out what's happening.

[Hendrik]

I'll have a quick peek at Gizmo later what it might be doing if nothing is playing.
Are you playing on the device, or controlling a remote zone?

[mwillems]

I'll have a quick peek at Gizmo later what it might be doing if nothing is playing.
Are you playing on the device, or controlling a remote zone?

We're primarily using Gizmo as a remote to control playback on the PC that won't sleep.  It's my living room HTPC, but it does double duty as my media server.  I don't typically stream to my device in Gizmo (I tested it a few times, but otherwise don't use that feature), and I don't think my wife uses streaming very often (although she does occasionally use it).

Honestly the sleeping part is of less concern to me than the "no screensaver" part.  I'd prefer things to function normally, but if I had to pick one, I'm more concerned about the screen than energy savings.

Thanks a bunch for looking into this 

[JimH]

Test using the stop button, rather than pause.

[mwillems]

Test using the stop button, rather than pause.

Will do, but to clarify, this happens when playback has finished: i.e. something was played two hours ago, and it ended on its own, but the PC won't sleep after playback has stopped.  I'll try manually stopping when playback is almost done to see if that works better than letting playback stop on its own.

[stevemac]

Hi,

It might pay to look at the power settings in Windows as well (I don't know the correlation between what MC shows and what Windows shows)

The next time it doesn't sleep run the following from a command prompt (with Admin privileges)

C:\Windows\system32>powercfg -requests

This should identifiy the process preventing the PC from sleeping,

Steve

[mwillems]

Ok I just woke up and went downstairs on a hunch and found the server's monitor still on with no screen saver (it had worked earlier in the day, so I thought it might have fixed itself).  

I checked system info and it showed "mode changed (disable screen saver, keep monitor on) (expired)." I waited five minutes and the entry didn't change or go away (and the PC had been left alone for quite a while prior).  I then force stopped gizmo and the power area in system info immediately cleared and the screen saver started  working again.  

I can reproduce the power tag by changing into theater view and then changing back into standard view.  That produces two of that tag, which count down, but one of them never clears after it expires.  Additional troubleshooting shows that it's linked to the "use full screen exclusive mode for drawing" check box in theater view options:
When that option is checked, the tag never clears.  When that option is unchecked, the tag clears normally.  

That may also explain why when I have "use full screen exclusive mode for drawing" checked, my screen saver never turns on in theater view, even though I don't have "disable screen saver in theater view" enabled.  That one has puzzled me for a while, but I thought it might just a side effect of using FSE for drawing.

So it doesn't seem to be Gizmo's fault, but for some crazy reason force stopping gizmo seems to be a way to clear the stuck tag (just a coincidence?).  

Hope this gives you something to go on.

[Hendrik]

Personally I wouldn't recommend the full screen exclusive mode, as it can interfere with video playback.
But I'll have a look if its causing your screensaver troubles somehow.

[mwillems]

Personally I wouldn't recommend the full screen exclusive mode, as it can interfere with video playback.
But I'll have a look if its causing your screensaver troubles somehow.

Noted, I won;t be using it anymore.  I previously didn't use FSE, but I started using it a month or two ago (right around when my SS problems started) because it fixed some long-standing focus-loss problems I and some other folks have been having that would temporarily break IR remote control:

http://yabb.jriver.com/interact/index.php?topic=86264.0
http://yabb.jriver.com/interact/index.php?topic=87917.0

I'll be turning off FSE, and I guess on the focus issue, I can just go back to my old trick of delaying MC startup, which solved some of my focus-loss problems.

The repro steps for the problem I described above are:

1) Enable FSE for theater view
2) Change to theater view with Ctrl-4
3) Change to Standard view with Ctrl-1
4) Watch the power codes in system info, one of those two mode changes never seems to clear.

[Hendrik]

The focus problem is mostly due to auto-start? I always figured there are also issues during usage. Startup is a bit problematic, as other apps starting may steal focus, and no really good way to steal it back without potentially doing something disruptive for the user.
I suppose we could add an option to always ensure we have focus as long as MC is in theater view or display view or something like that - as long as its optional and people need to turn it on.

[mwillems]

The focus problem is mostly due to auto-start? I always figured there are also issues during usage. Startup is a bit problematic, as other apps starting may steal focus, and no really good way to steal it back without potentially doing something disruptive for the user.
I suppose we could add an option to always ensure we have focus as long as MC is in theater view or display view or something like that - as long as its optional and people need to turn it on.

There are occasional issues during usage, but the one time my system was guaranteed to lose focus was at startup, so delaying startup solved that category of cases.  I'd still lose focus occasionally other times, but the startup issue was the one I had to deal with almost every day.

I think I would like an option like that, and I think a few other folks would be grateful for it too.  My only concern would be that it would interfere with emergency exits from the program, i.e. alt-tabbing out if MC were frozen, using task manager, etc.  Although I guess task manager has it's own always-on-top-type status, right?

[Hendrik]

I found some other functionality in the OS to force an app into focus, while allowing the user to escape when he presses the ALT key or actively focuses another window.
I put it on my list to checkout.

[Hendrik]

The repro steps for the problem I described above are:

1) Enable FSE for theater view
2) Change to theater view with Ctrl-4
3) Change to Standard view with Ctrl-1
4) Watch the power codes in system info, one of those two mode changes never seems to clear.

I tried doing this, but it doesn't appear I can get the mode to stick here.

[mwillems]

I tried doing this, but it doesn't appear I can get the mode to stick here.

That's a puzzler.  It worked two or three times in a row when I tried it (and the tag stayed stuck for as long as I waited), but maybe there's some other setting I have ticked that's interacting with it.  I'll test again tonight, and see if I can isolate something else funny about my setup.

Potential additional avenue for inquiry: if you turn on FSE in theater view, switch to theater view and wait there, does your screensaver/sleep function work?  If it works when in theater view with FSE enabled, then I know I'm just experiencing something peculiar to my setup.  When I was using FSE, my screensaver/sleep would sometimes eventually work if I left it in standard view (it always took much longer than it should, and sometimes didn't work, but did occcasionally work); however (as noted above) the screensaver/sleep never worked in theater view when FSE was enabled. 

[Hendrik]

Screensaver works for me, even with Theater View in FSE mode.
May be a driver thing that prevents sleep while a FSE 3D app is running.

[mwillems]

Screensaver works for me, even with Theater View in FSE mode.
May be a driver thing that prevents sleep while a FSE 3D app is running.

Maybe that's it; I'm currently running the latest non-beta NVidia drivers, I'll try rolling back and seeing if that resolves it.  More troubling is that none of that quite explains why force stopping Gizmo seemed to resolve some of the issues and not others.  The issue definitely started in my system a few months ago (around when I started using both FSE and Gizmo), and my testing seems to suggest that it's related to one or both.  

The in-laws are coming to town for a week, so I'm probably not going to be able to do in depth troubleshooting soon (and things are currently working correctly for me without FSE), but when I've next got a few hours to myself with the server I'll try testing through various permutations to try and rule things out.

I'll try:
1) different display drivers
2) a different display output (MoBo as opposed to Nvidia)
3) toggling FSE,
4) different Gizmo activity states, and
5) any other potential settings I can think of.

If you can think of anything else I should test or try, let me know.

[mwillems]

Ok I did some additional testing.

1) I tried a few different NVidia drivers (latest non-beta, and the last two WHQL releases before), that didn't seem to affect anything.
2) The MoBo output resulted in normal screen turn off and sleep behavior, except that Gizmo tended to delay screen turn off or sleep behavior. Gizmo would keep the screen on or the computer awake for somewhat longer than the "scheduled period," if I had interacted with Gizmo anytime in the last fifteen minutes or so. How much longer varied from five minutes longer to almost half an hour longer in one case.

3) and 4)

a) FSE on-  With FSE on in theater view with the NVidia card, my screen never turns off and the computer never sleeps.  When transitioning back and forth from theater view when gizmo has been active recently, the screen-on power code sometimes sticks (as described above).  If I force stop gizmo, or haven't interacted with it in a while, then screen saver and sleep works normally in standard mode, and changing back and forth never makes the code stick.

b) FSE off- Screen off and sleep mode work exactly like the MoBo output above in 2).  Screen saver and sleep work, but take slightly longer than the scheduled period when I've interacted with Gizmo recently.

Conclusions: All of that points pretty conclusively to something goofy in my NVidia drivers and how they interact with FSE mode, and coming in and out of FSE.  It looks like Gizmo may have a contributing role in the power code sticking during changeover, but I have no idea how that works as it's inconsistent.  The problem is not really present at all in my system with FSE off.

On my end, everything's working correctly in my setup now (since you fixed the focus  ), so I'm prepared to write this one off as a driver issue and walk away.  If there's anything you want me to test further, let me know.  Thanks for the expert help!