GNOME Bugzilla – Bug 786957
every song has its own album
Last modified: 2018-01-10 15:08:55 UTC
as the title says from v3.24 every song has it's own album so if i have album 1 with 5 tracks on it this will result in 5 albums displayed and so on...already checked and all of my songs are correctly tagged...anyway to solve this?or at least i hope it'll get fixed for 3.26...
can you attach the 'tracker info <filename>' of 2 of the files of said album.
Created attachment 358683 [details] song 1
Created attachment 358684 [details] song 2
attached infos for 2 songs, even if maybe it happens with all the songs...
Created attachment 358688 [details] screen 1 seems it's not happening with every album, but anyway i'll attach some screenshots so you can better understand what i mean
Created attachment 358689 [details] screen 2
Well I can see in the tracker output that nie:contentCreated value is wrong. It is set to some datetime in 2017, while it really should be the date the content was created (aka a DATE tag or something similar giving the _release date_ of the album/song). This causes the datetime between songs to differ, which makes tracker think they're separate albums. Now it might be interesting to see if it is a problem in the actual tag or in the tracker interpretation of the tag. So could you check the tags of one of the songs you gave here and post them here? I think mutagen is quite a reliable tag parser for a lot music formats (https://mutagen.readthedocs.io/en/latest/). Also post the 'gst-discoverer <file>' output for the same song, this is a gstreamer tool to check file information and tags.
everysong is tagged by musicbrainz picard which already use mutagen...so you already have the output of mutagen...now i'll try with gst
well gst-discoverer <05-Hanno Ucciso L'uomo Ragno.m4a> result only in a > symbol while gst-discoverer "05-Hanno Ucciso L'uomo Ragno.m4a" resulted in command not found
Where is the output of mutagen, it is not in this bug. And gst-discoverer might have a version number attached (gst-discoverer-1.0) or be only available in a separate package, depending on your distro. 'command not found' clearly indicates it is not available as just that.
Created attachment 358723 [details] gst discoverer you had reasong...it had to be installed...here it is...
I'd still be interested in the mutagen output for this file. As you can see the date is probably the correct release year, it is however overruled by the incorrect date/time along the chain. The datetime tag shouldn't be set like that.
considering picard uses mutagen, don't you have the mutagen tag already?
No, the gstreamer (most likely) and in turn tracker tags are derived from the original file's tags and those are not provided here.
considering i don't know how to use mutagen, what if i use exfalso or quod libet insted, since they are tagged as mutagen products? (especially quod libet)
(In reply to luca from comment #15) > considering i don't know how to use mutagen, what if i use exfalso or quod > libet insted, since they are tagged as mutagen products? (especially quod > libet) It was only a suggestion, some tagreaders are just not that good and still don't provide what I need to know. Any of those are fine to me.
Created attachment 358943 [details] tag taken with mutagen
hope now you have what you need :)
(In reply to luca from comment #17) > Created attachment 358943 [details] > tag taken with mutagen This is not the mutagen output, its tracker. Just do 'mutagen-inspect <filename>'
Created attachment 359015 [details] mutagen here's the tag correctly taken with mutagen
(In reply to luca from comment #20) > Created attachment 359015 [details] > mutagen > > here's the tag correctly taken with mutagen The (c)day is the date tag, 1992. That's how it is reflected in the gst-discoverer output (date). However, there is also a date/time, which is probably the culprit. The latter one is picked up as the album date by tracker, which is wrong. The gstreamer issue is probably: https://bugzilla.gnome.org/show_bug.cgi?id=731029 . The tracker issue is (judging from your logs) just generating a default value based on the time the indexing is done. I assumed this was only done if there was no value returned for the tag by gstreamer, but somehow it is being provided here. That might need some looking into. It would probably be wise to either not provide this or make it less precise.
what do you mean by less precise? anyway i did not have these problems in gnome-music 3.22 so you may look at some changes you've done with the transition to 3.24...maybe anyway these songs had a rerelease in that year and tracker is picking that...it's likely that gnome music ha completely wrong years eh...
I have the exact same bug on Debian Testing with gnome-music 3.26. I would suspect that this bug is not related to gnome-music itself as it started to occur for me with version 3.22 just after the release of Debian 9 (Strtech). I don't know how things work with the tracker. I was suspecting some conflict with the cached tracker db so I have removed my cache folder and reloaded my session but the result was the same. I even tried to create a brand new session and download some music from Free Music Archive but the same problem occurred. Only a few albums are displayed correctly. a few others list the same song twice.
After investigating a bit more, I noticed that with the tracks having the problem, the 'nie:contentCreated' attribute is storing date+time ('2016-06-15T04:51:04Z') and with the tracks not having the problem, only the date is stored. Time is set to 0 ('2016-01-01T00:00:00Z'). I guess that this happens with audio files being tagged with a full date+time. Actually, only the year should be treated as it is the only date info that is set with most tags editors. I would suggest that GNOME Music ignores the month, day and time part of the 'nmm:musicAlbum' attribute when it is present.
I am having the same issue and can confirm the observation made by François in comment 24. All my MP3s having a nie:contentCreated without time (e.g.'2003-01-01T00:00:00Z') all my M4A files do have a time (e.g. 'nie:contentCreated' = '2006-08-14T11:16:21Z'). All Albums where there is no time given for nie:contentCreated are displayed corretly, all where there is a time given are not. My Gnome Music version is 3.24.2 and I am using it on Fedora 26.
I assume you all talk about m4a (or similar). This is a gstreamer problem as mentioned in comment #21.
this bug is from 2014...will we ever see this solved? :p
I'm seeing this issue still in 3.26.1 and I'm wondering if there's a work around until this bug gets fixed? It makes Music entirely unusable with my library of music which is 90% composed of m4a files.
-- 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/gnome-music/issues/119.