current Problem: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(DuplicateAlbums -> DuplicateAlbum``s (Imported from MoinMoin))
(No difference)

Revision as of 20:24, 6 December 2005

Current Problems

MusicBrainz, like any application, has some problems that cannot be resolved with a simple bugfix or implementing an idea from the NewFeatureSuggestions. In order to plan FutureWork, it is important to understand these problems and how users work around them now. Once we understand the problem better, a FeaturePage can be added and linked into the FutureWork list.

  • Please don't add a lot of discussion on this page -- add it to the pages linked below (or their Discussion pages, if any). For simple problems, it is better to file a bug report -- this page is intended for general or complex issues that will require significant related work to address.
  • The MusicBrainz server and client interfaces use a lot of BadTerminology that is confusing (especially to new users); while this Wiki has mostly been updated to use clearer terminology, it hasn't migrated to the rest of MusicBrainz.
  • One problem that many people run into is that when they make corrections to the database, the changes are not immediately applied, and they end up WaitingForModerations to be approved before the tagger can be used to update tags on music files. This problem also encourages LazyModerators to enter DuplicateAlbums or phony NonAlbumTracks.
  • With the increased popularity of MusicBrainz, the number of TrmCollisions has dramatically increased, and as a result the effectiveness of TRM matching is reduced. The PicardTagger is expected to help with this problem, but ultimately the TRM system might have to be abandoned: see GettingRidOfTRM.
  • The TrackNumber0Glitch, logged as bug number 834541 causes the tagger to return a track number of 0 if multiple TRM hits are found on a single album.
  • There has always been a tension in MusicBrainz between QualityVersusQuantity, with some people favoring QualityImprovements and others believing that a more open system can provide both QualityAndQuantity. While the AlbumLockingDiscussion has some specific proposals, this is a dialectic that will continue to exist as long as MusicBrainz does.
  • Another chronic problem with MusicBrainz has been the VotingBacklog, where there are too many open edits for all of them to be voted on. Now that the system accepts changes with no votes after a one or two week period, this is less of an issue, but it would not be surprising if this re-surfaces in the future.
  • Finally, VariousArtistsAlbums, due to their different implementation in the database, suffer from a number of usability problems; from not being able to EditAll information at once, to the fact that VariousArtists has no subscribers (and as a result changes to such albums are rarely voted on).

The current bugs list may also contain other problems that should have an entry on this page.