View Issue Details

IDProjectCategoryView StatusLast Update
0019518MMW 5Main Panel: Toolbars & Menuspublic2022-11-02 21:15
Reporterrusty Assigned To 
PriorityimmediateSeverityblockReproducibilitysometimes
Status closedResolutionfixed 
Product Version5.0.4 
Target Version5.0.4Fixed in Version5.0.4 
Summary0019518: In-place filename edits can result in tag writing error and DB deadlinks creation
DescriptionIn 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 Reproduce1 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 InformationNote: 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).
TagsNo tags attached.
Fixed in build2680

Activities

Ludek

2022-11-01 14:08

developer   ~0070072

Last edited: 2022-11-01 14:10

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

peke

2022-11-02 20:59

developer   ~0070111

Verified 2680

Unable to replicate.

rusty

2022-11-02 21:15

administrator   ~0070113

Verified 2680.