Bugzilla – Bug 5849
tagged genres lost/overwritten after MIP-enabled scan
Last modified: 2009-01-08 15:54:13 UTC
This bug applies to a file tagged with a list of genres. All genres on the list will be detected by SS/SC. However, rescanning with MIP enabled causes all but the first genre to be dropped. This one is similar to bug 4882, which applied to contributors. Here's the cause: when a file contains a list of genres, MIP for some reason only reads/records the first one in the list. Of course, SS/SC reads the entire list. When a MIP-enabled rescan runs, there appears to be a discrepancy between new and old values. As a result, a "cleanup" code purges all the old values and replaces them with the new info from MIP: the first genre only. As we discussed in bug 4882, this cleanup code--intended to allow for correction of typos--doesn't do all it's intended to: it only revises the info for that particular track. Old typos are left in the genre_track table, and a wipe is still required to remove a corrected typo from the database. The fix for bug 4882 involved elimination of the cleanup operation altogether.
Created attachment 2282 [details] sample file containing more than one genre
Created attachment 2283 [details] proof-of-concept patch which removes the offending code I've been using this patch for a while now, running scans with ActivePerl. It fixes the bug, but eliminates the superficial typo correction. I reason that since a wipe is required to fully correct typos (see comment 1), this is the preferable path. Comments welcome.
I'm not sure that it's right to require a wipe for editing a tag (if I'm reading you correctly). The new and changed is supposed to accept tag edits when the tagger software updates mtime when editting. won't removing this now create multiple genres on each edit?
Yes: this change will make both the old and the new genre visible under a given track after editing and rescan. (I concede this might be viewed as a step backwards.) I tested this out using SC7 on one folder (scanner.exe from the command line), using the genre "Ronk". Scanned. Corrected it to "Rock" & rescanned. Immediately after the scan, "Ronk" no longer appears when I browse that track, but it persists in the Genre list. The entry "Ronk" is still in genre_table. I will retest using a full rescan from the web interface & see if "Ronk" persists.
Okay, the cleanup code appears to work as intended: running a full rescan via the SC7 web interface removes the dead "Ronk" entry. (And truncates all my genre lists to ONE genre, see bug description.) Thanks, kdf; I apologize for posting nonsense. Unfortunately, this means a solution to this bug will have to be more complex.
windowshade are you still interested in working on this bug? Do I understand correctly that you want to use the (single) MIP tag, and merge in any tags that you have in your file? Or even ignore the MIP tag?
Sure, I'm interested but I don't know a shred of code. I'll keep testing, however, and report any new findings. For instance, this bug affects FLAC but not MP3 tags. Yes, my preference is to preserve/merge all the tags present in the file. (Personally, all I want from the MIP importer is the 'musicmagic_mixable' info.) I suppose MIP data should be included rather than ignored, though, since some users leave 'audiodir' empty and only import MIP data.
Ah okay. The 'real' solution to this problem probably ought to be options to select whether the user wants to use MIP genres, tag genres, or both. You might see if you can stir up some support on the forums. Otherwise I'm afraid this one is going to take a back seat to a lot of other issues. :(
What about checking the type of scan. wipe would not need to to the deleteAll, new and changed would only need to do it if the timestamp was changed (and then only during the FIRST appearance of the track in single scan cycle). The trouble comes when there are MIP updates causing a reload against existing data. Maybe a new genre entry coming from MIP could trigger a tag scan on that specific file to recreate all genres. Just a brainstorm, not sure if it's entirely possible, viable or when it could be implemented.
This is fixed in 7.3 with the "only read mixable status..." option. Many thanks!