Sorry for size and copyright reason, just ask me for the attachment and I will email it to you.

Created attachment 277493 [details]
example audio file

example audio file (4secs) - nautilus shows this as 2012 whereas rhythmbox shows this as Unknown

Hi - I've add a very short snippet of music showing this issue.

EasyTag shows the correct year (2012)

didnt see anything obvious when running rhythmbox -d

Is there any extra tracing I can add to see where rhythmbox is extracting the year as "unknown"?

commit 1d921b4 fixes reading of dates from mp4.  gstreamer's mp4mux element doesn't seem to be working properly for me, so mp4 tag writing doesn't work.  I'm probably not going to be able to look into that for a while.

Created attachment 277586 [details]
second example audio file showing the issue at hand

second sample (4 seconds) - as described, this time the year is reported as 1910 but nautilus says 2012

Hi Jonathan,

  indeed, this commit has fixed the "unknown" vs 2012 issue.  Thats good :)

I have, however, got another sample of music - this time, rhythmbox reports 1910 but Nautilus and EasyTag reports the year as 2012

gstreamer reads that one incorrectly.  Please file a new bug against gstreamer and attach the file.

thanks - filed here: https://bugzilla.gnome.org/show_bug.cgi?id=731029

Jonathan,

  just a quick update - I scratched together a python app to read and display the tags - using the gstreamer ElementFactory "playbin" - the date field is correctly extracted as 2012

For m4a files - what ElementFactory is rhythmbox using to extract tag information?

N.B. - if you want to run the app in the attachment the syntax is

python find_tags.py /full/path/to/the/attachment.m4a

Created attachment 277615 [details]
quick python application to display the tags of an audio file

The problem here is that reading this file results in both GST_TAG_DATE and GST_TAG_DATE_TIME tags, where the date time is correct (2012) and the datetime tag is apparently not (1910).  rhythmbox arbitrarily takes the datetime tag in preference to the date tag, so it shows the date as 1910.

if you're interested in the details of how rhythmbox processes tags: https://git.gnome.org/browse/rhythmbox/tree/metadata/rb-metadata-gst.c

That would explain why not all of my m4a files have invalid date.  Any album purchased on iTunes after 2011 have a wrong date.  I guess that they started using the GST_TAG_TIME tag at that period.

But why not change Rhythmbox given Nautilus, EasyTag, Clementine all show the correct year?

The code is generic at this stage - trying to catch dates and datetimes from multiple audio types.

There is definitely something different between python pulling a datetime and the C equivalent.

Python throws this error when trying to pull the date into a datetime

(python:3127): GStreamer-CRITICAL **: gst_tag_list_get_date_time: assertion 'GST_VALUE_HOLDS_DATE_TIME (&v)' failed

Gst.TagList.get_datetime(tag) in python returns False for this m4a file ... so in theory should drop into the get_date else clause and return the correct year.

The C API and Python API is acting differently - dunno why though.  

Its left me scratching my head.

@Jonathan,

  can I ask why the logic is datetime first before date? - if you reverse the logic, the two m4a files above are correct.  

I've mainly got ogg files in my collection.  A quick spot check - they remain correct.  I've checked the few mp3 and flac files in my collection - they remain correct.

i.e.

if (gst_tag_list_get_date (tags, GST_TAG_DATE, &dateptr)) {
			g_value_init (ret, G_TYPE_ULONG);
			g_value_set_ulong (ret, g_date_get_julian (dateptr));
			g_date_free (dateptr);
			return TRUE;
        } else if (gst_tag_list_get_date_time (tags, GST_TAG_DATE_TIME, &datetime)) {
			GDate date;
			g_date_set_dmy (&date,
					gst_date_time_has_day (datetime) ? gst_date_time_get_day (datetime) : 1,
					gst_date_time_has_month (datetime) ? gst_date_time_get_month (datetime) : 1,
					gst_date_time_get_year (datetime));

			g_value_init (ret, G_TYPE_ULONG);
			g_value_set_ulong (ret, g_date_get_julian (&date));

			gst_date_time_unref (datetime);
			return TRUE;
		} else {
			return FALSE;
		}

like I said, it's arbitrary.  I'm not changing it without understanding where these apparently wrong datetime tags come from.

I see that it is now set to "resolved".  I haven't seen a commit since May 30th regarding this but if I can help with the testing, let me know.  If you have something already compiled for Ubuntu 14.04 that would be even better as my compiling skills are limited.