After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638889 - [PATCH] Moving physical location of music already in library from A to B causes dupes
[PATCH] Moving physical location of music already in library from A to B cau...
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: general
1.9.1
Other Linux
: Normal normal
: 1.x
Assigned To: Andrés G. Aragoneses (IRC: knocte)
Banshee Maintainers
Depends on:
Blocks: 610800
 
 
Reported: 2011-01-07 07:59 UTC by coffeetastesawesome
Modified: 2011-05-10 22:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch, v1 (9.08 KB, patch)
2011-01-10 02:02 UTC, Andrés G. Aragoneses (IRC: knocte)
none Details | Review
Proposed patch, v2 (5.97 KB, patch)
2011-01-10 23:50 UTC, Andrés G. Aragoneses (IRC: knocte)
none Details | Review
Proposed patch, v3 (6.02 KB, patch)
2011-01-11 00:20 UTC, Andrés G. Aragoneses (IRC: knocte)
committed Details | Review

Description coffeetastesawesome 2011-01-07 07:59:13 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 #".
Comment 1 Andrés G. Aragoneses (IRC: knocte) 2011-01-07 22:56:35 UTC
I've seen this too.
Comment 2 Andrés G. Aragoneses (IRC: knocte) 2011-01-10 02:02:03 UTC
Created attachment 177906 [details] [review]
Proposed patch, v1
Comment 3 Andrés G. Aragoneses (IRC: knocte) 2011-01-10 23:50:59 UTC
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.
Comment 4 Andrés G. Aragoneses (IRC: knocte) 2011-01-11 00:20:56 UTC
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.
Comment 5 Alexander Kojevnikov 2011-05-10 13:46:27 UTC
Review of attachment 177994 [details] [review]:

Looks good.
Comment 6 Andrés G. Aragoneses (IRC: knocte) 2011-05-10 22:08:00 UTC
Comment on attachment 177994 [details] [review]
Proposed patch, v3

Thanks for the review!
Comment 7 Andrés G. Aragoneses (IRC: knocte) 2011-05-10 22:08:31 UTC
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.