View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0019518 | MMW 5 | Main Panel: Toolbars & Menus | public | 2022-11-01 02:28 | 2022-11-02 21:15 |
Reporter | rusty | Assigned To | |||
Priority | immediate | Severity | block | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Product Version | 5.0.4 | ||||
Target Version | 5.0.4 | Fixed in Version | 5.0.4 | ||
Summary | 0019518: In-place filename edits can result in tag writing error and DB deadlinks creation | ||||
Description | In build 2680 (test build), when I attempt to edit a filename in place (in Music > All tracks [List]), an error results and tracks are silently deleted from the DB!! | ||||
Steps To Reproduce | 1 Edit '00 - Benny Goodman - I've Got Rythm.mp3' to '00 - Benny Goodman -- I've Got Rythm.mp3' --> error message displays indicating Tag update failed. File xx is inaccessible (but Windows File Explorer shows that the filename _was_ edited). 2 Revert the edit --> It appears to occur successfully 3 Edit '00 - Benny Goodman - Peggy Lee...' to '00 - Benny Goodman -- Peggy Lee...' --> error message displays indicating Tag update failed. File xx is inaccessible (but Windows File Explorer shows that the filename _was_ edited). 4 Restart MM --> The '00 - Benny Goodman - I've Got Rythm.mp3' file is no longer in the DB! --> The '00 - Benny Goodman -- Peggy Lee...' is inaccessible because it has reverted to '00 - Benny Goodman - Peggy Lee...' Note: This occurred on a clean install of 2680 (test build) that had only a single directory scanned. | ||||
Additional Information | Note: I suspect that this may have the same root cause as what the user experienced in Ticket 4960 since it can result in DB entries with bad links (as in the case of the Peggy Lee file above), and then scanning the DB causes the correct link to be added, resulting in the appearance of duplicates). | ||||
Tags | No tags attached. | ||||
Fixed in build | 2680 | ||||
|
Good catch! This has been longstanding issue and really could cause DB deadlinks this way. It was not reproducible here, because of timing issue, there were paralel tasks, TASK1 changed the filename + updated DB, but TASK2 saved the track with old filename. The TASK2 shouldn't be there at all and whenever TASK1 was completed earlier the bug was there. => Fixed in 2680 |
|
Verified 2680 Unable to replicate. |
|
Verified 2680. |