GNOME Bugzilla – Bug 104203
rhythmbox should support Musicbrainz, not some random tag equality heuristic
Last modified: 2018-05-24 10:20:23 UTC
Many of the albums I have in my Rhythmbox playlist have subtly different names as a result of inconsistent user submissions to CD databases. It would be useful if Rhythmbox allowed for such subtle differences by treating album, artist, and song titles as the same in the relevant GUI panes even if the case of these fields is different (for instance Fatboy Slim == FatBoy Slim).
*** Bug 106541 has been marked as a duplicate of this bug. ***
*** Bug 119954 has been marked as a duplicate of this bug. ***
*** Bug 121584 has been marked as a duplicate of this bug. ***
*** Bug 123492 has been marked as a duplicate of this bug. ***
*** Bug 126770 has been marked as a duplicate of this bug. ***
*** Bug 126567 has been marked as a duplicate of this bug. ***
*** Bug 126340 has been marked as a duplicate of this bug. ***
The answer is Musicbrainz.
*** Bug 127769 has been marked as a duplicate of this bug. ***
*** Bug 127766 has been marked as a duplicate of this bug. ***
If I wanted to implement an interm solution to ignore case and white space at the beginning and end of a artist/album name where would I look in the code?
*** Bug 132611 has been marked as a duplicate of this bug. ***
*** Bug 137607 has been marked as a duplicate of this bug. ***
*** Bug 150909 has been marked as a duplicate of this bug. ***
I cannot think of one possible situation where an artist tag "UNKLE" would be different from an artist tag "Unkle". Can you? Didn't think so :) I don't believe MusicBrainz is the best solution in every case, not everyone has Internet access 100% of the time, and the problem is so simple and it's not "random" - it's logic. Sure, MusicBrainz support is great, but there is no need for tag case sensitivity. Remove tag case sensitivity please.
Don't forget: "Unkle" is the same as "Unkle " and " Unkle"
The browsers could be changed to be case-insensitive by changing the library-source property view and query from RHYTHMDB_PROP_ARTIST to RHYTHMDB_PROP_ARTIST_FOLDED (and similar for genre and album). This is going to be much slower than the current situation unless we change rhythmdb-tree to use the folded properties for it heirarchy instead of the normal ones. I can't think of any bad side-effects of this right now, but there probably will be some that may need to be dealt with. Another issue with this would then be that the names in the browsers would all be case-folded (in lower case, for English) - we would probably have to add a third property type to the property model for "Display" in addition to the matching and sorting properties. The current behaviour would be done with <match=ARTIST, sort=ARTIST_FOLDED, display=ARTIST> and the suggested behaviour with <natch=ARTUST_FOLDED, sort=ARTIST_FOLDED, display=ARTIST>. There would also be the issue of which display name to use when more than one exists, but I imagine that it would be done by using the first one that occurs. Something that is also related to this (and bug 139196) is that the browsers and searching could be improved by the *_FOLDED properties changing from being case-folded to "search-folded", which is like case-folded but also has punctuation removed.
I think musicbrainz is a must-have with the coming tag-editing possibility in mind. A similar functionality like the MusicBrainz Tagger for windows would be nice
*** Bug 332127 has been marked as a duplicate of this bug. ***
Unassign bug, nobody actively working on it, AFAICT.
Hey, Alex I hate to be a pain but is there any particular reason why you change so many bugs from UNCONFIRMED -> NEEDINFO -> NEW? That generates a large amount of spam email for us. I don't mean to take away from the good work you are doing - just wondering? Thanks.
(In reply to comment #23) > Hey, Alex I hate to be a pain but is there any particular reason why you change > so many bugs from UNCONFIRMED -> NEEDINFO -> NEW? That generates a large > amount of spam email for us. I don't mean to take away from the good work you > are doing - just wondering? Thanks. I was actually switching from ASSIGNED->NEW not from UNCONFIRMED, because the bug doesn't appear to be actually "ASSIGNED" to anybody (i.e. nobody is actually actively working on it, and gives the wrong impression of the true bug status). Also, there's no way to go from ASSIGNED back to NEW without going through NEEDINFO, unfortunately.
Alex, that sounds like a bugzilla bug. Could you file a bug under that component for adding an option under "Bug Reassignment" to put the bug back in the NEW state? In the meantime I would prefer not messing with the status field - I never look at it anyway. Anyway, I've said my piece. Thanks.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/8.