doesn't deal correctly with renames outside of rhythmbox

[PaulWay]

Binary package hint: rhythmbox

I am reporting this here because GNOME's bugzilla is broken - searching for 'directory' returns a blank page.

When you rename a directory in the Music library while RhythmBox is open, it thinks that the files are completely new. This causes all the tracks to lose their ratings, metadata, etc. The old tracks are still seen but are now unplayable, and when Rhythmbox restarts it then removes the old tracks as being unavailable.

Steps to reproduce:

1) Open rhythmbox with at least one directory of music files in the Library directory.
2) Rename that directory.

What should happen:

3) Nothing changes - the tracks remain the same, their metadata is preserved, and the paths to them are corrected in Rhythmbox's library.

What does happen:

3) The new directory is detected and the files are scanned, creating new music tracks in the directory.
4) The existing tracks are still present but unplayable.
5) When Rhythmbox is restarted, the existing tracks and their metadata is removed.

Package and OS info:

This is present in Rhythmbox 0.11.6.
I use Fedora 10, but the bug is present in versions of Ubuntu that ship with this version of Rhythmbox - e.g. 8.04
I have logged this bug here because it is not possible to search the GNOME bugzilla for this bug. I am applying for an account with their bugzilla in the hope that I can log this problem there as well.

[PaulWay (paulway)]

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

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

[Jeremy Visser (jeremy-visser)]

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.

[PaulWay (paulway)]

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.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

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

[PaulWay (paulway)]

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

[Chris Wilson (notgary-deactivatedaccount)]

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

[John Kuang (xiphosurus)]

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.

[Chris Wilson (notgary-deactivatedaccount)]

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?

[John Kuang (xiphosurus)]

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.

[Si Dedman (si-dedman)]

(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...

[James (ubuntu-soundunreason)]

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.

[Colan Schwartz (colan)]

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?