Bugzilla – Bug 717
Using external cuesheets results in duplicate entries in the db
Last modified: 2008-09-15 14:37:04 UTC
Using external cuesheets results in duplicate entries in the db. Depending on the metadata of the music file being referenced, the entire file may show up as "No Artist/No Album" entry, as an extra No Album entry for the artist, as an extra track at the end of the album, or replacing the last track on the album. The music file itself should be filtered out of the db when it's referenced from an external cuesheet.
to my mind, there are two cases that need to be accounted for in order to do this: 1) cue sheet read after audio file 2) cue sheet read before audio file. In case 1 when we parse the cue and find the file reference, we can check if that file exists in the cache and delete it. This works until the user navigates to that folder, which brings us to case 2. Case 2, we would need to have some way to check for the existence of files with same name, but appended with an anchor. A cache marker, like info{'hasCUE'} could be used, but we'd still have to know how to add it if the audio file is read after the CUE.
For flac files with internal cuesheets, we detect the existance of the cuesheet and then change the file's content type of the bare (no-anchors) file url to be a playlist type ("fec" in this case). This keeps the bare no-anchor file url from being listed as a seperate entity when browsing by artist/album/song/artwork/etc. We could try something similar for external cuesheets, though doing it across seperate files is trickier. Notably, we'd need to be able to set or change the content type of the bare file being referred to, whether we've parsed it yet or not. Then we'd need to make sure that when parsing the bare file, we don't stomp on that content type if it already exists. In this scenario, if someone added a new file and it's cuesheet to the system, and then managed to use "browse music folder" to navigate to it without parsing the cuesheet along the way, they'd have an incorrect entry until the cuesheet got parsed. This seems like a minor corner case with an easy workaround though.
Created attachment 224 [details] patch to apply new content type to files referenced by cuesheets Here's a stab at changing the content type for files referenced by cuesheets. I'm not sure exactly how to force one file to be parsed before the other as kevin suggested above, but this seems to work with whatever I throw at it.
for the record, I've tested this patch with both trunk and the 5.4.x branch.
assingin to vidur to look at wrt the new db...
does this patch work for any file with a cue sheet? for example, bug70 is a dupe of this bug, but I believe a the time it was specifically referring to mp3 files.
I've not personally tested this with mp3s that use cuesheets, but from the nature of the fix I expect it will apply equally to any format relying on an external cuesheet file.
Created attachment 285 [details] updated patch for 6.0 here's an updated attempt for recent 6.0 builds, of the same approach. While effective, it's not exactly efficent, as the bare file gets it's content type set again for each track in the cuesheet, instead of only once. But cuesheet parsing needs some reworking anyway in this respect, and this works for now.
Applied Michael's patch in subversion change 2265.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.