GNOME Bugzilla – Bug 638889
[PATCH] Moving physical location of music already in library from A to B causes dupes
Last modified: 2011-05-10 22:08:31 UTC
I'm running Ubuntu 10.10. I recently decided it was time to clean up my messy music collection. Instead of having things scattered around various locations. I moved the files from LOCATION A to LOCATION B (the new spot for all my music). Trouble was, Banshee didn't detect the files were moved. So from there I did Tools --> Rescan which completed successfully no errors. However, the double entries in the library remained. One for LOCATION A and LOCATION B. I had to manually remove the dupes that referenced LOCATION A using sqlite3 with the help of timH on IRC. "<timH> somehow dups got assigned to the same album/track #".
I've seen this too.
Created attachment 177906 [details] [review] Proposed patch, v1
Created attachment 177987 [details] [review] Proposed patch, v2 Simplified patch. The previous patch was doing too much stuff, maybe trying to be too smart, and really, an importing process should never delete elements, so I narrowed the use case of this for the case in which we only have one potential duplicate for each track.
Created attachment 177994 [details] [review] Proposed patch, v3 Improved things: - Avoid calling trackPrimarySourceChooser() if we find a dupe. - Renamed FindDupes to FindOutdatedDupe (singular instead of plural, and clarifies what type of dupe) - Changed visibility of new members from public to internal as we don't need to expose it. - Improved wording of the description of the commit so it is more understandable.
Review of attachment 177994 [details] [review]: Looks good.
Comment on attachment 177994 [details] [review] Proposed patch, v3 Thanks for the review!
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.