doesn't deal correctly with renames outside of rhythmbox

Finally figured out Bugzilla and submitted new bug for this problem:

http://bugzilla.gnome.org/show_bug.cgi?id=587483

I confirm this bug.

Nautilus doesn't suffer from this with thumbnails of images. .thumbnails has the thumbnails for your pictures, with the filenames based on the MD5 of some file metadata including the path. If you drag the image to another folder, the thumbnail's MD5 filename is updated to match the new file location.

I see two ways of doing this:

1) Have a hash for each of the filename, the path (without the filename), and the id3 tag data. If a file shows up as new, check whether there are matches on any of those three hashes. If two of them match and the third one doesn't, then it's probably been renamed, retagged, or moved outside Rhythmbox.

If one of the hashes matches but the other two don't, then it might be reasonable to check with the user whether they this is the same track as before. If a whole bunch of files have changed two hashes but kept a third, then it might be more reasonable to assume that e.g. a directory has been retagged or renamed.

2) Use something like musicbrainz, which can recognise a track by a musical 'fingerprint' of the audio. This allows tracks to be recognised even if the tags have been moved in the file, the file renamed, the path changed, and even the file re-encoded. I don't know how unique and reliable the fingerprint is, however.

Thanks for sending this upstream. Setting to "triaged".

Sebastian, I'm not sure if that's a helpful rename. In my opinion "deal correctly" doesn't mean much as "causes loss of metadata". The "outside (of) rhythmbox" is important, though, but since there's no way to rename a directory _inside_ rhythmbox I also think it's confusing the issue.

Hope this helps,

Paul

This is a pretty old bug report. Is it still an issue in 12.04 or 12.10?

Just checked in 12.10 with Rhythmbox 2.97. This bug is still present in that Rhythmbox still does not handle a directory name change correctly. The tracks are moved into "Missing Files" when a directory is renamed using Nautilus, with Rhythmbox open. However, the metadata can be recovered by renaming the directories back to their original names.

Does anyone have any idea how this should be handled? All the music players I've ever used, including Rhythmbox, Banshee, iTunes, Windows Media Player and Zune, fall down when you rename file paths outside of them.

Is there an elegant way we can have Rhythmbox pick up the new location en masse, thus preventing the user from having to reimport each track individually?

Rhythmbox already watches for new music files. Perhaps it should watch for removed files too, so the moment it detects the simultaneous removal and adding of a track with the same filename, it should interpret that as a directory change and just update the directory path in the database, leaving all metadata intact.

Either that, or perhaps have a new "Directory View" in which you can move tracks around and rename directories within Rhythmbox.

(IMO) The way to solve this is as per this ancient bug here: https://bugzilla.gnome.org/show_bug.cgi?id=538549
Even if there's no agreement with other FOSS music players about a shared standard (which would be a shame, for the record), it's so disappointing that this has lain dormant for >5 years, despite being a thorn in people's sides over and over again...

I don't know the mechanism by which the work is done, but (if memory serves) iTunes has (or had) a function to "Locate missing files". This would troll through your collection and attempt to locate (usually moved) files.

Upstream has moved to GitLab so go and upvote/subscribe at https://gitlab.gnome.org/GNOME/rhythmbox/issues/13.

Can Launchpad track GitLab projects now?