[frankvw]

I'm sure this has been asked before but I have searched and Googled extensively and not found anything. So here goes.

A well-known problem is that Musicbrainz has a lot of info, but rarely gives you what you want. Pink Floyd's "The Piper at the Gates of Dawn" was released in 1967, which is the date I want displayed in Kodi. However, Musicbriainz contains over 50 releases of that same album, which are re-releases on Vinyl, cassette, CD, "Remastered" CDs, "special edition" CD cases and what not. The problem is that the release date for each of these releases is the one for that particular version. Most (but not all!) of these MB entries contain an "originaldate" and/or "Original Date" tag, but Kodi doesn't use that; it simply displays the release that for that particular album. As other posters have already pointed out as early as 2013, no CDs were available before 1980, which means that according to Kodi, Pink Floyd's "Piper" was released in 1989, which is utter nonsense.

Yes, I do understand the need for MB to differentiate between, say, the Canadian release of Piper (which contained 11 tracks) and the American one (which contained 9 tracks in a different order and not all the same as on the original album, for reasons best known to the music industry at the time) and I also understand that when you let Picard do its own lookup you will end up with your original "Dark side of the Moon" CD being labeled as a Polish bootleg on cassette). But that's related to the fact that MB is a great idea from a technical standpoint but can be a disaster in terms of user experience, which is another matter entirely. What I'm battling with is the release date which, as displayed in Kodi, simply is the wrong one.

The solution is simple and obvious: use the original release date (if there is one) rather than the release date for whatever re-release MB has used. But Kodi doesn't seem able to do this. I've searched far and wide but this option doesn't seem to exist.

Yes, of course I could override all this manually using Picard or another tagger (and then I'd have to make sure that Kodi NEVER, EVER goes online to "update" my corrected details with the wrong ones again) or simply do everything by hand. But my library currently contains over 135,000 tracks and I might die of old age (or, more likely, Kodi and MP3 will become obsolete and be replaced with something else entirely) before I'm done.

So. How in the name of all that's unholy do I get Kodi to use the original release date rather than the date for whatever re-release CD I have?

[DaveBlake]

So. How in the name of all that's unholy do I get Kodi to use the original release date rather than the date for whatever re-release CD I have?

I understand what you want and I want the same myself. I really hope I can broaden the optional use of the various date tags in v19, I will try to prioritise that (I have done so many things in v18 that I don't personaly use, I think I deserve one for me).

Meanwhile Kodi gets song year really simply, so if you just edit the value tags that Picard sets for YEAR (Flac files) or TYER, TDRC and TDRL (mp3) that is what Kodi wuill use. Editing tags is not great, but it is an option and you sound prepared to go to extremes!

Album year is initially derived from the music file tags (first song on album), but can be set via album.nfo file. This gives an alternative approach - apply an edited NFO file. Perhaps easier than modifying the tags?

[HeresJohnny]

I think this is already on @DaveBlake 's ToDo list. For the moment the date displayed depends on how you curated your tags. If you just applied musicbrainz tags you're shit out of luck for the moment, as MB writes the (Re-)release date in the date tag and creates another tag "original release date". Personally, I hate that and I want it just the other way around: The original release date goes in "date" and the re-release date goes under "released" (in my case). Of course that means editing all your tags manually or using some kind of script. If you want to do what I did, use foobar2000 (or the editor of your choise) to copy the "date" tag to another tag like "released" and then copy values from "original release date" to "date".

Until this is implemented in Kodi as a user choice as a database table + a skin display option, I don't see another way. Who knows if it's ever going to happen, since there will surely be two warring factions - those who want to use the MB tagging scheme and those who want another scheme like myself. If @DaveBlake finds the time to implement a second date tag, in the end he will model it after his own preferences I guess.

[HeresJohnny]

I understand what you want and I want the same myself. I really hope I can broaden the optional use of the various date tags in v19, I will try to prioritise that (I have done so many things in v18 that I don't personaly use, I think I deserve one for me).

That's great to hear, but no rush. Would it be possible at all to make tag selection a freely editable user choice in advancedsettings?, like
Re-release tag =
Original release tag =

[frankvw]

So. How in the name of all that's unholy do I get Kodi to use the original release date rather than the date for whatever re-release CD I have?

I understand what you want and I want the same myself. I really hope I can broaden the optional use of the various date tags in v19, I will try to prioritise that (I have done so many things in v18 that I don't personaly use, I think I deserve one for me).

Meanwhile Kodi gets song year really simply, so if you just edit the value tags that Picard sets for YEAR (Flac files) or TYER, TDRC and TDRL (mp3) that is what Kodi wuill use. Editing tags is not great, but it is an option and you sound prepared to go to extremes!

Album year is initially derived from the music file tags (first song on album), but can be set via album.nfo file. This gives an alternative approach - apply an edited NFO file. Perhaps easier than modifying the tags?  

Hi, Dave! Once again thank your for replying!

An option to select between two ID3 (or similar) tags and use the original year rather than the current media release year would be great, and I expect this would be widely popular if other threads  in this forum are anything to go by. I have no idea what the inside of Kodi looks like, but a configuration option to select between two ID3 (or similar) tags doesn't seem a very complicated feature to implement. But then, I'm speaking from ignorance so it's easy for me to say that! At any rate, I'd be grateful and I don't think I'm the only one.

Meanwhile I'm looking into a scripted way (on Linux) to copy the original release date tag to the current release date tag on all my audio files. That should get me there for the moment.

Once again thanks; your efforts are greatly appreciated!

[HeresJohnny]

Let's not get offtopic here, we've had those discussions about the usefulness of MB in other threads. To be fair, the implementation of MB in Kodi - or any web service of that kind - is a good solution for the beginner to average user.

[scott967]

I agree it's probably not worthwhile to argue over the semantics of TYER vs TORY, let along which interpretation is "right"  or "wrong".  Bottom line is it would be useful of have the option of scanning TORY to the database with analogous album nfo entry.  I'm not sure a global setting to use one or the other would work, as it seems to me the semantics will vary based on music type/genre.

scott s.
.

[HeresJohnny]

And to add insult to injury, of course the field names differ in IDv2.3 and IDv2.4 and are not standardized in VorbisComments... And of course, personally I don't care about MP3, only about FLAC :-)

[DaveBlake]

@frankvw you had some this to say about how Musicbranz id tags are handled that I have split into a separate thread to discuss rather than clutter this one off topic see https://forum.kodi.tv/showthread.php?tid=343532

[DaveBlake]

Back to discussion of possible original date etc. handling.

The first step is to read these tags and store the values, but that doesn't do anything for users. I prefer to have all the data in the library then decide how to use it than make it a tag scanning option, where changing the setting means rescanning everything. That will make the db larger, but that doesn't seem to be an issue.

Yes I will have to decide what Vorbis comments to process, and how to equate them to the equivalent ID3 tags. Making the name of the tags read totally configurable is a little radical, I would rather keep Kodi to applying tagging standards and common practice where possible. Give too much flexibility and users will get in a mess.

The big question is how does filtering and sorting by year optionally make use of this additional data. It makes most sense to me to make what values are used for year optional, than add "original year" nodes, filters and sorting in addition to year nodes, filters and sorting.

Bottom line is it would be useful of have the option of scanning TORY to the database with analogous album nfo entry. I'm not sure a global setting to use one or the other would work, as it seems to me the semantics will vary based on music type/genre.

Not sure how such a thing could be made optional depending on genre (or any other album/song property) - for these take year from here, for those take it from there.... yikes!

A fallback strategy could work - which date tag takes prescedence - but would be applied globally across the library.

Open to hear ideas

[scott967]

Back to discussion of possible original date etc. handling.

The first step is to read these tags and store the values, but that doesn't do anything for users. I prefer to have all the data in the library then decide how to use it than make it a tag scanning option, where changing the setting means rescanning everything. That will make the db larger, but that doesn't seem to be an issue.

When I suggested "option" I meant that user would have the option of populating the tag in their music (using whatever semantics they prefer), not that Kodi would have a setting to read the tag.

scott s.
.

[HeresJohnny]

Even reading the "YEAR" tag is a misery. MB lets users fill it with anything that resembles a date, starting from YYYY over YYYY-MM to YYYY-MM-DD. Best just take it as text.

[DaveBlake]

When I suggested "option" I meant that user would have the option of populating the tag in their music (using whatever semantics they prefer), not that Kodi would have a setting to read the tag.

Thanks for clarifying Scott.

Yes the date tags can contain partial dates e.g. YYYY or YYYY MM, and other date formats, all needs to be allowed for (or users trained to tag in a suitable format)

[meowmoo]

I did not read everything in this post, just wanna throw in an easy solution that I use for my music.

You can use a simple script in musicbrainz Picard, so the original date gets written in the date tag, and voila kodi shows the original releases date.

Open the scripting tag in Picard and add

$set(date,%originaldate%)

Thats all

Ps: you need to retag your music of course

[BatterPudding]

Even reading the "YEAR" tag is a misery. MB lets users fill it with anything that resembles a date, starting from YYYY over YYYY-MM to YYYY-MM-DD. Best just take it as text.

MB does not "let users fill it with anything".  There is a very limited edit box on that page that will only accept numbers.  So the ONLY dates in that field will be in the format you are showing.  YYYY or YYYY-MM or YYYY-MM-DD

MB has its good and bad points, but please don't make things up.  I've spent a couple of years over there and they are just as mad as this forum. 

Trouble is that our music is precious to us all - and we all are fussy people who want the tags in OUR way. 

You can use a simple script in musicbrainz Picard, so the original date gets written in the date tag, and voila kodi shows the original releases date.

Open the scripting tag in Picard and add

$set(date,%originaldate%)

Thats all

THIS is the answer for now. Picard is a mad program full of confusion - but it can be tamed. And once tamed ALL those odd weirdnesses of MB can be ironed out.


Now where this is a headache is the fact that "Original Date" in MB relies on someone having uploaded an original release of your chosen album.  Which often doesn't happen.  So you can have a CD in your hands printed in 1990 which was a re-issue of a 1977 vinyl.  Problem is, if no one has manually uploaded that 1977 vinyl to MB then there will be no "original date".  This is why we may need some way to tell KODI to override the date it is reading in the files.