View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0022233 | MMW 5 | Now Playing | public | 2026-07-15 18:54 | 2026-07-17 14:49 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | unable to reproduce |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | - | OS Version | 11 |
| Product Version | 2027 | ||||
| Target Version | 2027 | Fixed in Version | 2027 | ||
| Summary | 0022233: Playing Queue can be lost | ||||
| Description | I've now observed this twice, once on 20024 and once on 2027. During crashes and force close of MediaMonkey from Task Manager, there is a very small chance the Playing queue gets wiped. I don't know what triggers this (maybe a crash on writing to queue) and am not able to reproduce nor have logs. The most that can be done right now is probably a review of what code could allow for this to happen. Maybe MediaMonkey should create a copy of the m38u file before modifying it, and remove this copy on successful modification? Either an automated recovery or user can manually (via File Explorer) restore when this happens. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 3515 | ||||
|
|
Fixed in build 3515. MediaMonkey now saves the Playing list to mediamonkey.m3u8.new and then atomically renames it to mediamonkey.m3u8, while keeping a backup of the previous list in mediamonkey.m3u8.bak. This should resolve an issue where a crash occurring during the save process could cause the Playing list to be lost. On startup, if MediaMonkey detects that mediamonkey.m3u8 is missing, corrupted, or incomplete, it restores the file from the *.bak backup. |
