View Issue Details

IDProjectCategoryView StatusLast Update
0019063MediaMonkey 5Generalpublic2022-05-25 12:02
Reporterrusty Assigned To 
Status feedbackResolutionreopened 
Product Version5.0 
Target Version5.0.4Fixed in Version5.0.3 
Summary0019063: Crash when resuming from sleep on systems using 'Modern standby'
DescriptionThis bug was originally raised at 0019008. On systems that use S0 (=Modern Standby) to sleep (rather than S3, which has been used traditionally), MediaMonkey experiences problems on resume such as:
- movement of the seekbar control
- crash

Michal confirmed that these issues are caused by "modern standby". Windows stops MM threads in just a few ms and ignores MM requests to briefly postpone sleep (by SetThreadExecutionState and/or PowerSetRequest), so MM's state (playback, etc.) isn't fully saved prior to going to sleep, resulting in issues on resume (these threads continue after waking up and then try to save state and prepare for sleep, even though the system is already waking/restoring state).

Partial workarounds were implemented in 0019008:
- prior to build 2260: the system would sometimes start playing by itself at step 5.
- prior to build 2262: the system would display the MM taskbar in green at step 5, but that issue was fixed (by disabling the progress bar for thumbnail generation).
Steps To ReproduceThis can be replicated as follows:
1 Launch MM
2 initiate playback and press PAUSE
3 Close laptop to trigger Sleep mode
4 Open laptop
--> Screensaver displays
5 Click mouse (on a portion of the screen where MediaMonkey isn't displayed)
--> Apps display, but after a few seconds the MM seekbar indicator disappears and then re-appears!
6 Repeat steps 3-5 4x
7 Close MM
--> Crash AD2A0000
Additional InformationInfo re Windows Power System states:

Systems can be configured to either enter S0 ("modern standby") or S3 for sleep, but it's not possible to switch between these modes (it's configured by the OEM in the OS image), and more and more systems are being set up with 'modern standby'.

powercfg /availablesleepstates can be used from the Command Prompt to determine sleep states supported on a system.
TagsNo tags attached.
Fixed in build2623


related to 0019008 closedmichal Wake from sleep 2x causes Taskbar to "progress" indefinitely and Playback to start by itself 
has duplicate 0018283 resolvedpetr Crash or Black screen on resume from sleep/hibernation (5.0.2 logi ID 4AD4000) 
related to 0018958 closedLudek "Unknown thread" exception after PC wake up on playback restoring 



2022-05-08 14:03

developer   ~0068058

Improved in build 2623. Now it should behave more reliably on S0 systems. Not sure, if we could do more, as Modern Standby is really hard to handle, because it stops threads way too quickly and does not allow us to do much.


2022-05-10 18:19

administrator   ~0068081

Tested 2623
- Resume after sleep while paused: In 10 tests, it started playback 1 time on its own.
- Resume after sleep while playing: In 10 tests, it resumed playing all 10 times

So the issue seems to occur much less often, but leaving as resolved for additional testing of the 1st issue on other systems.


2022-05-12 21:46

developer   ~0068129

Last edited: 2022-05-12 21:48

View 2 revisions

Tested 2624 and I get same results as you in 0019063:0068081

There are additional fixes/test case for 2625 as noted in 0018958:0068121


2022-05-13 20:17

administrator   ~0068136

Tested 2625, and playback still unpauses by itself on resume from sleep about 1/10 times.

Considering it's minor and infrequent, I suggest pushing this issue (i.e. to close this bug and open a issue specifically about 'unpausing' with a post-5.0.3 target). Please triage.


2022-05-17 17:08

developer   ~0068150

Last edited: 2022-05-17 17:09

View 2 revisions

I tested on borrowed notebook with S0 and it did not happen to me at all, I tried ~ 30 times. The only way I found is in this "click to display" step, in case I have mouse cursor in the place, where play button is displayed, it does unpause, but this is expected, as I clicked where the play button was and the button received click event. Could not be your case too?
Anyway, I am not sure if we can do more in this issue.