View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019483 | MMW 5 | DB / Backup | public | 2022-10-20 15:55 | 2022-10-27 00:26 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | unable to reproduce |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0.4 | ||||
| Target Version | 5.0.4 | Fixed in Version | 5.0.4 | ||
| Summary | 0019483: 'DB / Tag mismatches' keeps showing some tracks with certain Extended tags | ||||
| Description | Analyzing the issues reported here: https://www.mediamonkey.com/forum/viewtopic.php?p=501982#p501982 and Ian shared his sample track and DB with me. I found that scanning the track to my DB correctly shows Extended tags as 'date: 2003' and is added to DB.Songs.ExtendedTags as [{"title":"date","value":"2003"}] but in his DB the value is [{"title":"date","value":"2003"},{"title":"date","value":"2003"}] i.e. "doubled" for some reason. What is worse that upon selecting the track and "Update tags (Ctrl+S)" the value isn't corrected to [{"title":"date","value":"2003"}] and file is still shown in 'DB / Tag mismatches' node. Test note: This happens with MP3 files | ||||
| Steps To Reproduce | 1) Select MP3 file (isn't reproducible with FLAC) 2) Go to Properties > Custom and insert the same tag twice like this: date: 2003 date: 2003 3) Go to DB / Tag mismatches => track is shown there with Extended tags highlighted 4) Right click, Update tags, press F5 to refresh => track is still shown i.e. in the DB the tag is twice, but in the file tag itself it is always once | ||||
| Additional Information | https://www.mediamonkey.com/forum/viewtopic.php?t=102666 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2676 | ||||
|
|
As MP3 cannot contain the same custom tag twice then the solution should be rather to remove the duplicate tag from DB |
|
|
Fixed in build 2675. MP3 tagger now can store multivalues to extended tag and tag editing removes duplicate entries before saving (i.e. same title and value). "Update tags" functionality now also removes duplicate extended tags from DB. |
|
|
Reopened Looks like it still can be triggered. |
|
|
Are you sure you tested the right release? In 2675 you are not able to do step 2, so what you mean by "still can be triggered". Please specify repro steps. |
|
|
I retested again and I ma not being able to replicate issue, but both users are replication g it in 2675 See https://www.mediamonkey.com/forum/viewtopic.php?p=502047#p502047 |
|
|
I think I replicated it. This happens for tracks that were imported from MM4 database (MM.DB), but were not re-scanned into database thus inludes ExtendedTags = null in MM5.DB (while it has extended tags in the file tag). Suggested solution (to be implemented): 'Update tags' will run re-scan operation that updates _only_ the tags in question (i.e. to prevent unintended consequences for any tracks that have DB/Tag mismatches). i.e. for those tracks having ExtendedTags = null in the database it adds the values from file tags. Same for bps and bit-depth (related to 0019279 ) |
|
|
Another repro steps: 1) delete extended tags from some file 2) go to DB / Tag mismatches -> the file is there, even though we just saved same tags to DB and file. |
|
|
Fixed in build 2676. Problem was in saving emtpy extended tags. Possible re-import of new tags after DB upgrade will be solved for 5.1, issue 0019279 |
|
|
Verified 2677 |
