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 104203 - rhythmbox should support Musicbrainz, not some random tag equality heuristic
rhythmbox should support Musicbrainz, not some random tag equality heuristic
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: User Interface
0.4
Other Linux
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 106541 119954 121584 123492 126340 126567 126770 127766 127769 132611 137607 150909 332127 (view as bug list)
Depends on:
Blocks: 133444
 
 
Reported: 2003-01-23 06:57 UTC by now michael@endbracket.net
Modified: 2018-05-24 10:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description now michael@endbracket.net 2003-01-23 06:57:06 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).
Comment 1 now michael@endbracket.net 2003-06-03 03:39:15 UTC
*** Bug 106541 has been marked as a duplicate of this bug. ***
Comment 2 Sean Harshbarger 2003-08-03 11:09:37 UTC
*** Bug 106541 has been marked as a duplicate of this bug. ***
Comment 3 Jan Arne Petersen 2003-08-18 10:44:49 UTC
*** Bug 119954 has been marked as a duplicate of this bug. ***
Comment 4 Mark Humphreys 2003-09-09 13:31:19 UTC
*** Bug 121584 has been marked as a duplicate of this bug. ***
Comment 5 Colin Walters 2003-11-12 05:33:00 UTC
*** Bug 123492 has been marked as a duplicate of this bug. ***
Comment 6 Colin Walters 2003-11-12 05:33:54 UTC
*** Bug 126770 has been marked as a duplicate of this bug. ***
Comment 7 Colin Walters 2003-11-12 05:34:27 UTC
*** Bug 126567 has been marked as a duplicate of this bug. ***
Comment 8 Colin Walters 2003-11-12 05:37:08 UTC
*** Bug 126340 has been marked as a duplicate of this bug. ***
Comment 9 Colin Walters 2003-11-24 02:38:40 UTC
The answer is Musicbrainz.
Comment 10 Colin Walters 2003-11-24 02:39:05 UTC
*** Bug 127769 has been marked as a duplicate of this bug. ***
Comment 11 Colin Walters 2003-11-24 02:39:25 UTC
*** Bug 127766 has been marked as a duplicate of this bug. ***
Comment 12 John McCutchan 2003-11-24 03:48:48 UTC
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?
Comment 13 Colin Walters 2004-01-27 01:34:40 UTC
*** Bug 132611 has been marked as a duplicate of this bug. ***
Comment 14 Colin Walters 2004-03-26 02:08:52 UTC
*** Bug 137607 has been marked as a duplicate of this bug. ***
Comment 15 Vincent Noel 2004-09-16 20:22:04 UTC
*** Bug 150909 has been marked as a duplicate of this bug. ***
Comment 16 Nek Caw 2005-09-10 03:21:44 UTC
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.
Comment 17 John McCutchan 2005-09-10 20:26:45 UTC
Don't forget: "Unkle" is the same as "Unkle " and " Unkle"
Comment 18 James "Doc" Livingston 2005-09-11 04:17:26 UTC
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.
Comment 19 pavel 2005-09-13 11:18:30 UTC
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
Comment 20 pavel 2005-09-13 11:19:46 UTC
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
Comment 21 Alex Lancaster 2006-02-22 14:24:34 UTC
*** Bug 332127 has been marked as a duplicate of this bug. ***
Comment 22 Alex Lancaster 2006-02-22 14:26:11 UTC
Unassign bug, nobody actively working on it, AFAICT.
Comment 23 William Jon McCann 2006-02-22 14:29:48 UTC
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.
Comment 24 Alex Lancaster 2006-02-22 14:35:27 UTC
(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.

Comment 25 William Jon McCann 2006-02-22 14:45:10 UTC
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.
Comment 26 GNOME Infrastructure Team 2018-05-24 10:20:23 UTC
-- 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.