Bug 315329

(In reply to comment #0)
> I have several tracks that I have on multiple albums.  They are all tagged
> using information from musicbrainz.

This may be the cause of the problem - perhaps the same musicbrainz id is assigned to those tracks.

> It then points you to
> http://userbase.kde.org/Amarok/Manual/Various/
> TroubleshootingAndCommonProblems#Duplicate_Tracks, but I think that's not
> really useful.  I can perfectly understand if the files have identical
> information, like it's the same album/track.  But in this case the albums
> are different.

I've significantly improved that answer, please have a look at it now and perform the suggested investigation/remedy.

(In reply to comment #1)
> (In reply to comment #0)
> > I have several tracks that I have on multiple albums.  They are all tagged
> > using information from musicbrainz.
> 
> This may be the cause of the problem - perhaps the same musicbrainz id is
> assigned to those tracks.

They have the same musicbrainz_trackid (and musicbrainz_artistid), but different musicbrainz_albumid

> > It then points you to
> > http://userbase.kde.org/Amarok/Manual/Various/
> > TroubleshootingAndCommonProblems#Duplicate_Tracks, but I think that's not
> > really useful.  I can perfectly understand if the files have identical
> > information, like it's the same album/track.  But in this case the albums
> > are different.
> 
> I've significantly improved that answer, please have a look at it now and
> perform the suggested investigation/remedy.

I think the "loog" there should be "look".

So I did the --newid on one of the tracks, and after it's done amarok shows me the same dialog box again, but it now only gives the mysql errors about duplicate entry when inserting into urls and tracks.

Anyway, I don't think people should be manually adding ids to files for amarok to be able to deal with a recording being on multiple albums.

(I also find it unfortuanate that picard uses musicbrainz_trackid for this instead of something like musicbrainz_recordingid, because it's the uuid of the recording not the track.)

(In reply to comment #3)
> (I also find it unfortuanate that picard uses musicbrainz_trackid for this
> instead of something like musicbrainz_recordingid, because it's the uuid of
> the recording not the track.)

I opened a bug with picard for that:
http://tickets.musicbrainz.org/browse/PICARD-398

> I opened a bug with picard for that:
> http://tickets.musicbrainz.org/browse/PICARD-398

To clarify, as I currently understand things musicbrainz_trackid used to identify a track, so in that case amarok would be correct in saying that it's the same and that it should only add this once.

But some time ago musicbrainz introduced a new database schema (NGS, https://wiki.musicbrainz.org/Next_Generation_Schema) and now has a concept of a recording which can be on multiple albums, and it seems picard uses the same metadata tag to store the recording that used to contain the track, and I think they should have renamed the metadata tag at that point.

(It's unclear to me if you can still get the track id.)

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > http://userbase.kde.org/Amarok/Manual/Various/TroubleshootingAndCommonProblems#Duplicate_Tracks
> > 
> > I've significantly improved that answer, please have a look at it now and
> > perform the suggested investigation/remedy.
> 
> I think the "loog" there should be "look".

Yes. It's a wiki, please correct it! :-)

> So I did the --newid on one of the tracks, and after it's done amarok shows
> me the same dialog box again, but it now only gives the mysql errors about
> duplicate entry when inserting into urls and tracks.

Hmm, it definitely shouldn't do this once you do the --newid. I guess restarting Amaork followed by full rescan doesn't help?

Anyway, because the musicbrainz id now identifies a recording, I think we should drop support for considering it a "track id", as it only makes problems.

(In reply to comment #6)
> Anyway, because the musicbrainz id now identifies a recording, I think we
> should drop support for considering it a "track id", as it only makes
> problems.

Yes, that looks like the best thing to do for now.

I think the mysql errors I get in case of (real) duplicates also need to be dealt with, I guess that belongs in a different bug?  Should I file a new bug about that?

(In reply to comment #7)
> (In reply to comment #6)
> > Anyway, because the musicbrainz id now identifies a recording, I think we
> > should drop support for considering it a "track id", as it only makes
> > problems.
> 
> Yes, that looks like the best thing to do for now.
> 
> I think the mysql errors I get in case of (real) duplicates also need to be
> dealt with, I guess that belongs in a different bug?  Should I file a new
> bug about that?

No, that is known already.

(In reply to comment #8)
> (In reply to comment #7)
> > I think the mysql errors I get in case of (real) duplicates also need to be
> > dealt with, I guess that belongs in a different bug?  Should I file a new
> > bug about that?
> 
> No, that is known already.

Is there a bug report? If not, I'd prefer if Kurt filled one as he provides nice info and steps to reproduce.

Hi,
it has been brought to my attention on 
https://bugs.kde.org/show_bug.cgi?id=315329 that MusicBrainz changed semantics 
of the "MusicBrainz id" stored in various meta tags in a way that we IMO 
cannot use it as track unique identifier any longer.

In short, the "MusicBrainz id" is now a recording id, and per [1], one exact 
recording may easily end up in more albums, for example the original one and a 
compilation one. This breaks Amarok's assumption of uniqueness and leads to 
"Duplicate Tracks Found, only one imported" problems.

[1] https://wiki.musicbrainz.org/Server_Release_Notes/20110516

Is it okay if I just drop support for treating MusicBrainz id as uniqueIds? We 
may introduce MusicBrainz id as a separate tag in future. 
(Meta::valMusicBrainzId or similar)

	Matěj

Git commit 216c18bdaf18acf28e9ca98b115623934c9b4401 by Matěj Laitl.
Committed on 21/02/2013 at 01:30.
Pushed by laitl into branch 'master'.

Drop support for treating MusicBrainz ids as track unique ids

No comments on my mail inquiry, which I treat as a consent. Since 2.6
the SqlScanResultProcessor should cope with changed track ids just fine.

CHANGES:
 * Problematic support for treating MusicBrainz ids as track unique ids
   was dropped; should avoid surprising "Duplicate Tracks Found" errors.

@Alberto, you'll probably need to rebase your patch as I've touched
MusicBrainzFinder.cpp
GUI: Mentions of MusicBrainz ids being useful for AFT (Amarok File Tracking)
     in various documentation need to be removed
CCMAIL: amarok-devel@kde.org
CCMAIL: Alberto Villa <avilla@FreeBSD.org>

M  +2    -0    ChangeLog
M  +0    -6    shared/tag_helpers/APETagHelper.cpp
M  +0    -6    shared/tag_helpers/ASFTagHelper.cpp
M  +0    -6    shared/tag_helpers/ID3v2TagHelper.cpp
M  +0    -6    shared/tag_helpers/MP4TagHelper.cpp
M  +1    -9    shared/tag_helpers/TagHelper.cpp
M  +0    -1    shared/tag_helpers/TagHelper.h
M  +0    -7    shared/tag_helpers/VorbisCommentTagHelper.cpp
M  +5    -4    src/core/meta/Meta.h
M  +0    -2    src/musicbrainz/MusicBrainzFinder.cpp
M  +0    -5    src/services/lastfm/ScrobblerAdapter.cpp
M  +1    -1    tests/core-impl/collections/db/sql/TestSqlTrack.cpp

http://commits.kde.org/amarok/216c18bdaf18acf28e9ca98b115623934c9b4401

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > I think the mysql errors I get in case of (real) duplicates also need to be
> > > dealt with, I guess that belongs in a different bug?  Should I file a new
> > > bug about that?
> > 
> > No, that is known already.
> 
> Is there a bug report? If not, I'd prefer if Kurt filled one as he provides
> nice info and steps to reproduce.

Myriam?

I can't find any indeed, maybe that was reports that came in through other means, so yes, a good report is very welcome.

*** Bug 315331 has been marked as a duplicate of this bug. ***

Git commit af8926a94268051124de8b16eef3b7eb95ac2772 by Matěj Laitl.
Committed on 21/02/2013 at 01:30.
Pushed by laitl into branch 'v2.7.x'.

Drop support for treating MusicBrainz ids as track unique ids

No comments on my mail inquiry, which I treat as a consent. Since 2.6
the SqlScanResultProcessor should cope with changed track ids just fine.

CHANGES:
 * Problematic support for treating MusicBrainz ids as track unique ids
   was dropped; should avoid surprising "Duplicate Tracks Found" errors.

M  +4    -0    ChangeLog
M  +0    -6    shared/tag_helpers/APETagHelper.cpp
M  +0    -6    shared/tag_helpers/ASFTagHelper.cpp
M  +0    -6    shared/tag_helpers/ID3v2TagHelper.cpp
M  +0    -6    shared/tag_helpers/MP4TagHelper.cpp
M  +1    -9    shared/tag_helpers/TagHelper.cpp
M  +0    -1    shared/tag_helpers/TagHelper.h
M  +0    -7    shared/tag_helpers/VorbisCommentTagHelper.cpp
M  +5    -4    src/core/meta/Meta.h
M  +0    -2    src/musicbrainz/MusicBrainzFinder.cpp
M  +0    -5    src/services/lastfm/ScrobblerAdapter.cpp
M  +1    -1    tests/core-impl/collections/db/sql/TestSqlTrack.cpp

http://commits.kde.org/amarok/af8926a94268051124de8b16eef3b7eb95ac2772