Print

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

[gtp600]

Recently upgraded Windows 10 PC from MC 24.0.78 (64 bit) to 25.0.114 (64 bit). Restored all MC settings from backup after upgrade.
Now the PC goes to sleep while serving audio files to remote device, which happens to be an IPad running JRemote.

MC 24 did not have this problem.

As you can see from the attached screenshots:
- The "Disable Display from Turning off" option in MC25 is enabled
- Windows 10 power option for Multimedia is set to "Prevent idling to sleep when sharing media". I have made no changes to Windows power options.

[RoderickGI]

You don't actually need either of those settings.

- The "Disable Display from Turning off" option in MC25 is enabled

That is only needed if you are outputting audio only via HDMI. Your AudioQuest DragonFly is a USB DAC, is it not?

- Windows 10 power option for Multimedia is set to "Prevent idling to sleep when sharing media". I have made no changes to Windows power options.

While that setting is fine, it isn't necessary for MC to keep the PC awake. MC handles that process directly. You can check if MC is preventing the PC from sleeping by going to "Services & Plug-ins > Reporter" in the left Navigation Bar, and checking the "Power" section. See attached image which shows MC preventing sleep while I am playing audio.


So, something else is going on. Particularly if MC says it is preventing sleep, and then the PC sleeps anyway.


EDIT:

Oh, wait.

I just tried using Gizmo to play audio from a MC Server, which played fine, but MC didn't add anything into the Power section of the Reporter. That isn't right. It should show it is serving to a device, and prevent sleep.

It looks like something is broken. MC seems to recognise when it is serving to another MC instance, but not when it is serving to a device, such as Gizmo on a phone. Something for JRiver to look at. MC25.0.114.

[gtp600]

RoderickGI - Thanks for looking at this.

I have the Linux version of MC25.0.114 running on another device, and the serving Windows 10 PC goes to sleep when serving audio files to that device as well.

Something is broken.

[Matt]

I just tried using Gizmo to play audio from a MC Server, which played fine, but MC didn't add anything into the Power section of the Reporter. That isn't right. It should show it is serving to a device, and prevent sleep.

It looks like something is broken. MC seems to recognise when it is serving to another MC instance, but not when it is serving to a device, such as Gizmo on a phone. Something for JRiver to look at. MC25.0.114.

Hi there.

I just tried and I see:
“Serving (disable automatic sleep, disable deep sleep)” when playing to Gizmo.

And the CSystemPowerManagerEntry seems like it's getting created correctly.

This is on Windows, not as sure about other platforms.

What are you running?  Any tips to reproduce?  Thanks.

[gtp600]

Matt/RoderickGI:

Here is another thing I noticed since upgrading to MC25.0.114 on my windows 10 PC.
1. Windows PC is sleeping.
2. Using Ipad with JRemote, try connecting to MC25 server on the sleeping PC.
3. PC wakes up consistently each time, however, JRemote fails to connect and reports "timed out".
    I don't recall this ever happening on MC24.

I mention it here because it's media network related, and perhaps related to the PC sleep issue.

[gtp600]

Any update on this issue? Is it being looked at?
I retested on MC 25.0.115 and PC still goes to sleep when serving audio files.

[RoderickGI]

Well despite what I noticed once above with Gizmo, we can't reproduce the problem. At least not consistently.

I just tried with Gizmo again, and with the new JRemote2 for Android, and both update the "Power" section of the "Services & Plug-ins > Reporter" view, and the PC is kept awake.

I didn't take enough notice of this though:

Here is another thing I noticed since upgrading to MC25.0.114 on my windows 10 PC.
1. Windows PC is sleeping.
2. Using Ipad with JRemote, try connecting to MC25 server on the sleeping PC.
3. PC wakes up consistently each time, however, JRemote fails to connect and reports "timed out".
    I don't recall this ever happening on MC24.

That sounds like the Wake On LAN network packets (UDP packets on Port 9) are getting through to the PC okay, but the connection from JRemote isn't getting through to the MC Server.

After you upgraded to MC25, did you updated your Anti Virus and Firewall settings on the Windows PC to allow MC25 rather than MC24 through? If you are just using Windows Defender on the PC, there is a thread called "Taming Windows Defender" on the forum. Here: https://yabb.jriver.com/interact/index.php/topic,114101.0.html

Check what you have for MC25 matches what you have/had for MC24.

Once you get JRemote waking and connecting to the MC Server again, check if the "Services & Plug-ins > Reporter" starts showing information under the Power section, to keep the PC awake while serving audio.


PS: There is a new version, MC25.0.115 out. I don't think it will help with this issue though.

[gtp600]

RoderickGI: Thanks for the response.

I know there's a thread out there for taming windows defender, but I have not set that up. Previous versions of MC worked just fine.
Regarding Windows firewall, it appears to be configured the same for both MC24 & MC25. As well, the firewall configurations must have been done
automatically, because I didn't make any manual changes, ever. Things just worked in previous versions. All I did was upgrade to MC25.
Want to make sure we're not missing something basic.

As mentioned earlier, the serving Windows 10 PC goes to sleep when serving files to any of the following:
- Ubuntu 18.04 running MC 25.0.115
- directly to my android phone (Gizmo)
- directly to ipad (JRemote)

I was watching the Services & Plugins Reporter today.
The message in the Power section transitions thru the following values within a few seconds of serving each audio file. Is this the normal behavior?
1- Serving (disable automatic sleep, disable deep sleep) ... appears when an audio file is initially sent
2- Serving (disable automatic sleep, disable deep sleep) [expiring in X seconds]
3- Serving (disable automatic sleep, disable deep sleep) [expired]
4- No entries that affect the system power state

The cycle 1-4 seems to repeat when the next file is served, and so on, until the PC sleep timer expires.

[RoderickGI]

I know there's a thread out there for taming windows defender, but I have not set that up. Previous versions of MC worked just fine.
Regarding Windows firewall, it appears to be configured the same for both MC24 & MC25. As well, the firewall configurations must have been done
automatically, because I didn't make any manual changes, ever. Things just worked in previous versions. All I did was upgrade to MC25.

I've bolded the important bits of your post.

I understand, but unfortunately Microsoft has been tightening security with each progressive update they are sending out. While a Windows Update may accept settings for an existing application when it is applied, when a new application is installled, MC25 in this case, security settings may not be automatically set up for it. I know. The settings should be set up. Or there should be a popup that asks for confirmation of a new setting, unless you have turned those off, as some people do, assuming that settings will just be applied. They used to be automatically applied, but they don't seem to be as often anymore.

Two things work against MC.
1. It is a niche application and not as common as many others, so it wouldn't be on any list to automatically get security clearance.
2. At each major upgrade MC installs an exe with a new version specific name in a new location. So it is seen as a new application, not an update or upgrade.

So, MC often needs some attention in security software. I can't say for sure that is the issue, but I would certainly look at taming Windows Defender as a next step.

The timing out of JRemote when you try to wake the PC and connect does point to something being wrong, in the network topology or security settings. Are both the Windows PC and JRemote on the same subnet? i.e. Do they both get their IP Addresses from the same DHCP server on your network?


The cycle 1-4 is pretty self-explanatory. When MC is asked to serve a file, it sets the Power conditions correctly. But for some reason, it doesn't realise that it is still serving files. Maybe each file is buffered quickly, so MC is no longer actually serving a file. Then maybe each track you are sending is long enough that the internal timer in MC for the Power condition expires.

Are you serving whole Playlists or Albums of files, or individual files? If MC knows it is serving multiple files, I would expect it to keep the PC awake.

Do you have a very short timeout in Windows for sleep timer?


I can't think of anything basic that we are missing. Maybe someone else has some ideas, or is seeing the same issue. I haven't searched the forum for others with the problem.

[gtp600]

RoderickGI:

So, MC often needs some attention in security software. I can't say for sure that is the issue, but I would certainly look at taming Windows Defender as a next step.

Thus far, I have added all the recommended Folder exclusions to Windows defender, including my media folders. No change, PC still goes to sleep.

The timing out of JRemote when you try to wake the PC and connect does point to something being wrong, in the network topology or security settings. Are both the Windows PC and JRemote on the same subnet? i.e. Do they both get their IP Addresses from the same DHCP server on your network?

Yes, all devices on same subnet & using same DHCP server. At no point do I see JRemote, Gizmo or Ubuntu/MC25 losing connection to the server once established.
If I disable Sleep mode on the serving PC, anyone of these devices will play forever, consistently.

Are you serving whole Playlists or Albums of files, or individual files? If MC knows it is serving multiple files, I would expect it to keep the PC awake.

Serving entire playlists, with a few hundred files.

Do you have a very short timeout in Windows for sleep timer?

Windows sleep timer is normally set for 2hrs. I have shortened it to various values while troubleshooting this issue. PC always goes to sleep right around the time set.
There is nothing intermittent about this problem for me.

[gtp600]

So, MC often needs some attention in security software. I can't say for sure that is the issue, but I would certainly look at taming Windows Defender as a next step.

Thus far, I have added all the recommended Folder exclusions to Windows defender, including my media folders. No change, PC still goes to sleep.

Went on to add some file and process exclusions to Windows Defender. See attachment. None of this made a difference.

Lastly, I have a second Win10(64)/MC25 PC, and as an experiment, I enabled Media Network on this machine and used it as a sever.
Same result. Serving PC goes to sleep about the time the PC sleep timer expires.
So both of my Win10/MC25 installations have the same issue, and it's not intermittent.

[RoderickGI]

Have you ever looked at the Windows Command Line program, Powercfg? It is run in a Windows Command window, and shows a lot of stuff what is happening regarding power events.

In particular, the commands:

powercfg /systemsleepdiagnostics

and

Powercfg /systempowerreport

can show a lot of information, such as "System Idle Events" and "Power Requests". You might be able to find some indication of what is happening using that tool. Perhaps compare what happens when you play using MC24 with what happens with MC25.

You could also log the problem in MC, and see if the CSystemPowerManagerEntry value is being set on your system, as it is for Matt.

[gtp600]

RoderickGI:

I reinstalled MC24.0.78 on a windows 10 machine last night, and as expected, everything works. I noticed when I start a lengthy playlist, the
"Serving (disable automatic sleep, disable deep sleep)" parameter gets sent to 20 minutes.

In MC25, this parameter gets set to only a few seconds. As you alluded to earlier, MC25 doesn't seem to realize a playlist has been requested,
just an individual file. I'm pretty sure this is why the PC goes to sleep.

Firewall settings look consistent between MC24 & MC25, and Windows Defender taming doesn't seem to make any difference on MC25.

I'm going to try a fresh install on MC25 sometime today, without importing any settings from previous installation, and see what happens.

[gtp600]

I'm going to try a fresh install on MC25 sometime today, without importing any settings from previous installation, and see what happens.

The fresh install made no difference either.

[RoderickGI]

It does sound like a bug, but it needs to be reproducible for JRiver to fix it.

So the question is, what conditions make the bug show up? What is different about your environment?

I'm afraid I don't have answers to those questions. Matt? JRiver?

Maybe comparing a short log showing the correct playback on MC24, and another from the failed playback on MC25, will show what is going wrong. Apparently the CSystemPowerManagerEntry parameter is the key, so a search for that in the logs might show the differences.

[gtp600]

RoderickGI:

I do appreciate your help on this. I would have guessed someone from JRiver would have tried to reproduce by now. The scenario is straight forward.
1. Connect to JRiver Library Server using JRemote (I have JRemote v3.30, running on ipad with IOS 10.x)
2. Select a sizable playlist from JRemote, and start playing.
3. Everything works fine, up until the PC goes to sleep when using MC25.

I've attached two log files for comparison.
- They are from different computers, but both PCs are running latest versions of Win10 (with latest cummulative updates).
- Neither PC has any Windows Defender taming configured.

Log-Win10-MC24 ... (MC24 PC)
Log-Win10-MC25 ... (MC25 PC)

[RoderickGI]

Thanks for the logs. I had a look but they didn't help. So I ran some tests on my systems and they didn't help either!

Matt, I assumed that the "CSystemPowerManagerEntry" value would appear in the logs, but it doesn't seem to. I just see entries like;
0000593: 3384: General: CMCUICore::SystemPowerManager_UpdateActions: Start
0000593: 3384: General: CMCUICore::SystemPowerManager_UpdateActions: UI Mode: -999; Playing: 0
0000593: 3384: General: CMCUICore::SystemPowerManager_UpdateActions: Finish (result: 0) (0 ms)

But anyway, I think I have reproduced the problem.

This was a hint:

3. PC wakes up consistently each time, however, JRemote fails to connect and reports "timed out".
    I don't recall this ever happening on MC24.

I can't test with JRemote because I am an Android user, and JRemote2 for Android doesn't support WOL yet. Besides, it is a completely different program. But you have an Android phone and use Gizmo, so you can test in the same way I did. I tested again using my HTPC server. This is what I found.

1. First, I set the HTPC to go to sleep after one minute. Hybrid Sleep is allowed on the HTPC, but it is set to never Hibernate.
2. I let the HTPC go to sleep.
3. I started Gizmo and tried to connect to the HTPC. It woke the HTPC and connected.
4. I selected an Album (Album "5" by J.J.Cale, mp3 files from 2:14 to 3:13) and started playback. Each track was longer than one minute.
5. The first track played fine, and during the track the HTPC went to sleep.
6. The second track started playing fine.
7. After a short section of the second track, the HTPC woke up again.
8. The second track completed fine, the HTPC went to sleep again, and the next track started playing.
9. Steps 5 to 8 repeated for the third to the sixth track.
10. The seventh track never started playing. Gizmo displayed an "Error communicating with server" message. The HTPC wasn't waking.

11. I connected to the HTPC from my Workstation PC, which woke the HTPC.
12. Gizmo didn't recover and start playing again. It kept trying though, by the look, keeping the phone screen on and displaying the error message. Eventually, Gizmo fell back to failure mode and displayed the "Resume Playback" message without controls. Trying to resume playback just showed the Playing Now screen and same error message as before.


So, for the first six tracks I thought you had a problem with JRemote not waking your MC Server as required when it needed to buffer more audio. But obviously, the answer isn't that simple. Later I checked the Reporter on the server at track changes, and it did change to various "Serving" messages, which progressively expired, and eventually dropped them all, until Gizmo needed the next track to be retrieved, at which time a set of Serving messages happened again.

The first six tracks last 16:56 (mm:ss), with the seventh taking it up to 19:50.

13. Gizmo had to be restarted twice to get it to connect to the HTPC again. Even then, when I started playing tracks on it again (5 by J.J.Cale) I kept getting "Error communicating with server" messages, even when Gizmo was active and the HTPC was awake. The HTPC went to sleep once during the first track, and then didn't go to sleep again. I assume the constant attempts at communication from Gizmo were keeping it awake, but there were no Power messages in Reporter. Even though the HTPC never slept again, Gizmo kept playing until the first bit of the seventh track, and then stopped again. The server was awake. Gizmo was active with the "Error communicating with server" message flashing. How could this happen? Note: Gizmo was set to download the first 10 tracks, but it was waking the HTPC well before that, during the second and subsequent tracks. I did think I had a bad track in the seventh track for a while, but it could be played individually on all Clients and the Server.

14. I rebooted both the HTPC and the phone, then repeated the test without touching either once I started playback, other than to wake the phone screen and check progress. All fourteen tracks played to the end. I did see some "Error communicating with server" messages, but not on all tracks, and not near the end of the Album. The HTPC MC Server just kept sleeping and waking as required. When the Album started to repeat I hit Stop, which took a while to actually stop playback even though the HTPC was awake, with errors showing on Gizmo, but it worked.

15. I repeated the test above using my Workstation as the MC Client (MC25.0.115) and the HTPC as the MC Server (MC25.0.98), using the same tracks as above, (Album "5" by J.J.Cale, mp3 files from 2:14 to 3:13). Playback failed during the fourth track, with the HTPC not being woken to serve the remainder of the track.

16. I updated the HTPC MC Server to MC25.0.115. For reference, in am runing Windows 10 Version 1903 Build 18362.535.
  a. I repeated the test above using my Workstation as the MC Client (MC25.0.115) and the HTPC as the MC Server (MC25.0.115), using 16/44.1 FLAC files in the range of 2:50 to 3:00 mm:ss. The first test failed on the fourth track, with the HTPC not being woken.
  b. I wasn't watching very closely, so I repeated that test. It took a while for the HTPC to go to sleep during the first track, and then it failed to wake the HTPC for the second track.
  c. I repeated the test, watching closely this time, and it failed 9 seconds into the third track. The HTPC wasn't woken. Interestingly the bold highlight in Playing Now on the Client progressed to the fifth track, without actually playing anything. I guess the Client was trying to play following tracks after I clicked Ok on the "Something went wrong with playback" message? The third track was still the selected track though. When I clicked Play the HTPC was woken and the third track played, but only the third track. The HTPC wasn't woken to serve the fourth track, and the "Something went wrong with playback" message eventually popped up.


I think that is enough testing. There is definitely something wrong with power management when playing to a Client, be it another installation of MC, Gizmo, and possibly other Clients. The issue seems to be on the Server end.

Matt, I didn't produce logs. If you think they would help I can do that later. But gtp600's logs didn't show anything significant as far as I could tell.

[gtp600]

RoderickGI:

Thanks very much. This is exactly the behavior I'm seeing.
With short PC sleep timers, I've seen the Gizmo client wake up the computer (repeatedly) when the next track is needed.
However, neither JRemote or Linux/MC25 clients do this. If PC goes to sleep in middle of playlist, it continues to sleep.

BTW, just for kicks, I installed an earlier version of MC25 (.108) just to see if a recent update may have caused the issue.
No luck, MC25.0.108 has the same problem.
 

[gtp600]

1.5 months old and still waiting. Is a fix planned for MC25?

[Awesome Donkey]

If I had to guess, very likely MC25's development has concluded since MC26's development is under full swing, and if there's something to fix it'll likely be fixed in MC26.

[Hendrik]

MC currently only keeps the PC active during an active file transfer, and when a single track is too long it could fall asleep in between tracks.

I suppose MC should stay awake for the length of a track after it was requested for playback, so a remote client gets a chance to request more tracks, without having to hope that WOL works (and even if it does, it could be slow resulting in interruptions regardless)

[RoderickGI]

The length of a track plus the normal period it holds the PC awake would be good, so that there is time for the next request and transfer. Though I guess that happens before the end of the track anyway.

I was thinking the length of the Playlist, but that would be bad if the Client cancels playback, leaving the server awake for longer than necessary.

[gtp600]

Hendrik

MC currently only keeps the PC active during an active file transfer, and when a single track is too long it could fall asleep in between tracks.

RoderickGI

The length of a track plus the normal period it holds the PC awake would be good, so that there is time for the next request and transfer. Though I guess that happens before the end of the track anyway.

MC24 works. MC25 is broken.
Why not simply fall back to way the timer was calculated in MC24? As mentioned 3 weeks ago, MC24 sets the timer to around 20 minutes.
What prompted the change in MC25 in the first place? Having to wait until November 2020 for a stable version of MC26 seems a bit much.