Print

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

[gtp600]

Windows 10 PC with MC26.0.22. (This same problem was reported on MC25...see related posts in that area if interested.

Simply connect to MC Library sever, and select a playlist that's longer in duration than the serving PC sleep timer. (I've used both JRemote/Ipad and MCxx/Linux clients).

Using MC reporter to view events, you can see that the expiration time of the event "Serving (disable automatic sleep, disable deep sleep)" gets set differently between releases:
- MC26/MC25 sets the expiration of this parameter to just a few seconds whenever a new track is requested.
- MC24 sets the expiration of this parameter to around 20 minutes whenever a new track is requested, and I've never seen the serving PC go to sleep.

As virtually every track in my music library is longer than a few seconds, the serving MC26/MC25 PC is guaranteed to sleep because the
"Serving (disable automatic sleep, disable deep sleep)" parameter won't be active.

[Matt]

I believe the timer goes away once MC finishes serving.  Maybe your device reads the whole file at once?  Set the computer sleep time to be longer if it's a problem.

[gtp600]

I believe the timer goes away once MC finishes serving.

Yes, and that's exactly the problem. How does this make any sense when the client is processing a lengthy playlist?
And it's different behavior than in MC24 (which actually does prevent sleep as the parameter/event name would suggest).

Why was this functionality changed in MC25/MC26?

[Matt]

It was this change from January 2019:
Changed: Sleeping after serving a file will be allowed after 5 seconds instead of 20 minutes.

Before that the system would prevent sleep for a long time after serving and I didn't like that.

[gtp600]

Well, from this customers perspective, you guys deleted a very useful feature which only made media networking more robust, with no real negative side affects.

Why you would choose to do this, and then tell customers to implement a workaround is very confusing to me.

[RoderickGI]

That would be fine Matt, if all clients and remotes woke the MC Server again (reliably, in a timely manner) when they needed the next track in a Playlist. They don't. In fact, most don't.

It wouldn't matter so much if the Windows Sleep Timer is reset when MC serves another file. But it appears that may not be happening (not sure), and if so when the cumulative time since the first track was served exceeds the Windows Sleep Timer setting, the Windows PC will sleep. I tested a bunch back here: https://yabb.jriver.com/interact/index.php/topic,123034.msg854575.html#msg854575, but I was using a Windows Sleep Timer of 1 minute for that. Maybe if I set the Windows Sleep Timer to more than the longest track in a Playlist, which is usually the case on my HTPC, the PC wouldn't go to sleep. But note also my steps 1 to 12, that eventually Gizmo stopped waking the HTPC, even though it should have kept doing that.

So there is an issue. WOL requests work for a number of times from Gizmo, and then stop working. I have no idea why that happens, and it is a separate issue to the Windows Sleep Timer setting.