View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019063 | MMW 5 | General | public | 2022-05-06 23:23 | 2023-02-06 13:58 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.4 | Fixed in Version | 5.0.3 | ||
| Summary | 0019063: Crash when resuming from sleep on systems using 'Modern standby' | ||||
| Description | This 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 Reproduce | This 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 Information | Info re Windows Power System states: https://docs.microsoft.com/en-us/windows/win32/power/system-power-states https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby 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. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2623 | ||||
| related to | 0019008 | closed | michal | Wake from sleep 2x causes Taskbar to "progress" indefinitely and Playback to start by itself |
| has duplicate | 0018283 | closed | petr | Crash or Black screen on resume from sleep/hibernation (5.0.2 logi ID 4AD4000) |
| related to | 0018958 | closed | Ludek | "Unknown thread" exception after PC wake up on playback restoring |
| related to | 0019379 | feedback | michal | Playback issues on resume from sleep on systems using 'Modern standby' |
| related to | 0019791 | closed | michal | MMW5 crashes while running in background (A3FB7F44) |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
Retested on 5.0.4.2662 debug and the stability issues are resolved, but the minor playback-related issues remain (tracked at 0019379). |
