View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016906 | MMW 5 | Now Playing | public | 2020-08-25 11:02 | 2021-03-22 21:46 |
| Reporter | michal | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0016906: Now Playing position is not saved (in some cases) | ||||
| Description | Application does not save NP position, it is lost after app restart. (regression 2264) | ||||
| Steps To Reproduce | 1) run MM5 2) change currently playing track in NP list with several tracks 3) restart MM5 -> it loses NP position from 2), no track is highlighted or currently playing track is set to previously saved position, not the last one. | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?p=472004#p472004 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2327 | ||||
|
|
Verified 2265 Settings are preserved. Tested in normal close and abnormal close/terminate |
|
|
This issue seems to be occurring again in recent builds. It seems to be related to making a config change. i.e. 1 Initiate playback of 1000 tracks starting with track 50 2 Restart MM 3 Press PLAY --> Playback restarts at track 50 as expected 4 Make a config change in MM (e.g. enable/disable the Layout>Preview) 5 Double-click track 40 (to change the currently playing track) 6 Restart MM --> track 50 is shown as the currently playing track This was reported by a user in the forum as well several builds back so it's not a new regression, but I can get it to occur fairly easily. https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=98549 |
|
|
I can't replicate, but based on the log MM wasn't terminated as expectred and this was the reason for the Playing scroll offset not to be stored. It seems that changing the Layout in Options is somehow causing MM to not terminate correctly sometimes, investigating... EDIT: maybe it is a coincidence, but if I have compiled with Eureka and I can replicate the bug as described. Without Eureka I am unable to replicate. And as you indicated this happened with the old Eureka too. So there seems to be something between Eureka and ceflib/Chromium causing the render process not to be terminated correctly after a change in Options > Layout is done. EDIT2: Further findings: Even simply visiting 'Options > Layout' tab (and canceling) results in the bug on closing EDIT3: Further testing revealed that the bug is somehow related to shared dialog windows, it does not happen when dlgOptions is opened with 'notShared: true' param -- and the bug occurs also when canceling e.g. Properties dialog (though not always) |
|
|
Assigned to Petr, details discussed via IM Further testing note: The bug seems to occur only with multi process compilation (not replicated on single process) |
|
|
I've just reproduced the issue also on single process compilation (and I also already reproduced it without Eureka). Multi process compilation with Eureka just increases the chance to replicate the issue. So far the cause is still unknown, but is somehow related to opening and closing dialogs in the "shared window" mode. Then subsequently after closing those shared invisible windows (before closing the app) somehow causes that the main window fails to close properly. Assigned back to me to try to isolate the real cause (though it is hard job as the issue does not always happen). Workaround is to open all dialogs in the not shared mode, but this would slow down opening dialogs significantly. |
|
|
I haven't had much success to replicate the issue today, but I have made some changes and workarounds that are preventing this issue from happening. Fixed in 2327 |
|
|
Verified 2327. |
