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 707964 - generated album / album-disc urns not very unique
generated album / album-disc urns not very unique
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Extractor
git master
Other Linux
: Normal normal
: ---
Assigned To: tracker-extractor
Depends on:
Blocks:
 
 
Reported: 2013-09-12 11:26 UTC by Christophe Rhodes
Modified: 2013-10-03 13:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (6.17 KB, patch)
2013-09-12 11:26 UTC, Christophe Rhodes
none Details | Review
updated patch (use ':' for separation) (6.17 KB, patch)
2013-09-18 11:05 UTC, Christophe Rhodes
committed Details | Review

Description Christophe Rhodes 2013-09-12 11:26:47 UTC
Created attachment 254769 [details] [review]
patch

There are plenty of albums out there with the same title as another.  Current tracker-extract would generate the same album URI for them, which confuses consumer applications (such as gnome-music).

For music formats which have additional album-level information in the metadata, include that extra information (albumartist or similar) in the generated URI.
Comment 1 Martyn Russell 2013-09-16 16:19:01 UTC
Hello Christophe, first, thanks for the patch! :)

It makes sense, the URI is actually just supposed to be unique inside Tracker AFAIK, so using the regime you came up with looks like a fine idea.

My main concern is that there will be some extractions where we don't know the artist and you still end up with the same problem. Mind you, we would still have that problem now anyway.

I would use ":" instead of "." for the separator too - it's more in line with the way we store URNs currently. Other than that, you missed the MP3,totem and xine extractors with your patch.

Any chance you could update your patch to include those changes and extra extractors? Thanks!
Comment 2 Christophe Rhodes 2013-09-16 16:39:54 UTC
The mp3, totem and xine extractors have no way of getting extra album information (such as the albumartist) -- there's no album artist metadata in the idv3 spec, and I have no idea what metadata totem and xine store but at least in the existing tracker code there's no other album-level information stored that I can see.

It is not possible to use track artist for this disambiguation, because that would cause e.g. compilations to have multiple uris, one for each track-level artist.  As you say, my patch at least makes these cases no worse than current behaviour; there is a minor change in behaviour, in that previously e.g. mp3s with the same album title as flacs with albumartist metadata would be grouped together in a single album, and with my patch they wouldn't be; I would tend to argue that this is a good thing, but there might be users out there who disagree.

As for changing '.' to ':', sure, I can do that if it's necessary.
Comment 3 Christophe Rhodes 2013-09-18 11:05:10 UTC
Created attachment 255160 [details] [review]
updated patch (use ':' for separation)

As discussed in the previous comment: does not patch the mp3, totem or xine extractors due to information loss, but does change the separator character betweem album and albumartist from '.' to ':'.
Comment 4 Christophe Rhodes 2013-09-25 10:10:42 UTC
This has gone ominously quiet.  I'm aware of a historical lack of engagement around a useful treatment of per-album metadata; see for example bug 335168, bug 318579, and doubtless others.

Is there any concern that the patch I have provided is not a net improvement over what is currently implemented?
Comment 5 Martyn Russell 2013-09-26 07:03:55 UTC
(In reply to comment #4)
> This has gone ominously quiet.  I'm aware of a historical lack of engagement
> around a useful treatment of per-album metadata; see for example bug 335168,
> bug 318579, and doubtless others.

I've just not had time lately. I do this in my spare time and I run a business. I used to be paid to manage the project and had more time then so ...

We do offer services around Tracker if companies want to speed up development of the project ;)

I will get around to this soon. Other bugs have likely not been committed because we don't want to break things. I will take a look at those too when I next have time.
 
> Is there any concern that the patch I have provided is not a net improvement
> over what is currently implemented?

Nope. :)
Comment 6 Martyn Russell 2013-09-27 16:00:58 UTC
Comment on attachment 255160 [details] [review]
updated patch (use ':' for separation)

Thanks for the patch, go ahead.
Comment 7 Martyn Russell 2013-10-03 13:44:14 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.