GNOME Bugzilla – Bug 733830
While extracting music from CDs, information in the "Year" field is lost
Last modified: 2015-12-25 06:52:44 UTC
With Sound Juicer installed, Rhythmbox can rip CDs. When a CD is inserted and selected, it displays editable information, including the year of the release (which is often automatically filled in from MusicBrainz). When the "Extract" button is clicked in Rhythmbox, it copies these files to the library, including their metadata, but the information in the year field is lost. After the CD has been extracted, the songs in the library list the year as "Unknown".
The "Sort Artist" field is also ignored on extracting media.
I'm also having this issue. BTW is the "Sort Artist" field ever used anywhere?
As far as I have used it, the sort artist field is used to sort the artist (yeah, it's basically as it's labelled). For instance, if you change the Sort Artist of an artist named "Aardvark" to "Zoo" then it'll be located after "Zodiac" when you sort your music by artist, instead of being up with the A's before "Apple".
Well, I just ripped a CD to FLAC format today. The 'Sort Artist' field was preserved, only the 'year' is lost. Guess we should rip to every format available to check this?
On ripping to m4a VBR, the year is preserved but the "Sort Artist" is ignored not in the sense of not showing anything, but no matter what you write on "Sort Artist" the information gathered from MusicBrainz overrides it.
*** Bug 746293 has been marked as a duplicate of this bug. ***
Created attachment 317687 [details] [review] Patch that fixes the bug I have recently encountered this bug and see that it has been reported 1.5 year ago and it still has not been fixed in git master! I have look into the RB source code and found a simple solution. This patch fixes the missing year tag both for MP3 files and FLAC files. I haven't tested other file formats (like Ogg) but I think it should work too. Details: Apparently, Gstreamer has two date tags GST_TAG_DATE (type GDate) and GST_TAG_DATE_TIME (type GstDateTime). RB only sets the first one, and I guess that the tag setter used by RB is just reading the other one (bad luck). This patch makes RB sets both gst date tags, so we don't care which date tags is read by the tag setter.
pushed as commit f7b3610; thanks for figuring out what was going wrong here. I adjusted the code style a bit and also added the missing gst_date_time_unref to avoid leaking the GstDateTime object.