Looking to use %originaldate% so Plex properly sorts my music library for a given artist

Looking for Plex users that can tell me how they solved the problem of Plex using medium release date (labeled as “Date” in the metadata tags) rather than Original Release Date or Original Year tags. The only thing I can think of is overwriting the Date tag with the value of Original Release Date or Original Year, which to me feels like data loss regarding the history of the album.

Any better ideas out there?

2 Likes

Perhaps you could copy the release date to a new tag such as Release Date and then overwrite it with the originaldate tag? Something like:

$set(Release Date,%date%)
$set(date,%originaldate%)

At least that way there wouldn’t be any “data loss” in the metadata stored in your files.

4 Likes

Okay, so how does “Release Date” get saved to the metadata? Or, should I be doing this in the triggers, not the file naming script?

This should be in a tagging script and not in the file renaming script.

1 Like

Yeah, that is close. The problem is when I do:

$set(Date,%originaldate%)

I wind up with two “Date” tags in the meta data. If I save the changes, then when I load the album back into Picard, the “Date” metadata tag has two dates listed in it and yet another “Date” tag is created. Not sure why $set( ) is not updating the existing “Date” tag.

Try using date all lower case like $set(date,%originaldate%) and see if that works for you.

Okay, even closer. I’ve got the two $set( ) statements doing what you proposed they would do. Now, when I save the album, remove it from Picard’s right window frame, and then reload the album, I’m getting what I see in the screenshot I’ve included. Basically, saving the album is creating a tag named “media release date” and then the trigger script is adding a new entry for “Media Release Date”. I’ve updated the script to the following:

if($not(%media_release_date%),
$set(Media Release Date, %date%)
$set(date, %originaldate%),)

The goal was to see if “Media Release Date” already existed as a tag, if it did, skip running the this trigger script. For the value I’m passing to the $not( ) function, I’ve tried the following values:

%Media Release Date%
%media release date%
%Media_Release_Date%
%media_release_date%
Media Release Date
media release date
Media_Release_Date
media_release_date

The last four variations were hail mary attempts. I’m wondering how one know determines what the script variable name will be for a tag name or if tags I’m creating won’t have script variable names. I ask because I’m surprised that none of the examples above worked.

2 Likes

This won’t do what you expect because you’re checking for a tag with underscores but then setting a tag with spaces. To check for a tag with spaces, you need to use the $get() function instead of the percent signs. For example, something like:

$if($get(Media Release Date),,
$set(Media Release Date,%date%)
$set(date,%originaldate%))

As for what tags Picard uses and how they are mapped, check out the Tag Mapping appendix in the Picard User Guide.

1 Like

I also had my logic reversed. Here is my script now:

if($not($get(media release date)),
$set(media release date, %date%)
$set(date, %originaldate%))

Okay. I saw your suggestion of looking at the Tag Mapping appendix. I actually already saw that and did not find my answer there. I’m reading how I phrased my question in my last response and I don’t feel I was being clear. Let me try to explain my question this way…

In my script above, I’m saving %date% to a tag I’m creating named “Media Release Date”. However, when I save the album, the tag is renamed to “media release date”. So, the difference is titlecase before saving and all lowercase after saving. I’m wondering how to predict how the name would be saved for a custom tag and how can I assure the custom tag will save with the letter casing I am choosing? Yes, this is my OCD kicking into high gear, but I prefer my scripts to do what I predict and not make arbitrary changes. :slight_smile:

Also, thank you for all your help, @rdswift. I’m still untangling the scripting part of Picard.

1 Like

How the tags actually get stored is something that I don’t really understand very well. @outsidecontext is my go-to person with these kind of questions. I expect that he’ll post something to help clarify when he sees this.

1 Like

@rdswift - I look forward to his view on the subject.

There are basically two cases to distinguish here: Tags Picard knows about and for which it has format specific mappings, and tags it does not now about.

date is a known tag. Picard maps it to the appropriate tag depending on format. E.g. for ID3 it will end up in a TDRC frame, for MP4 as ©day and in Vorbis / FLAC tags as DATE.

Everything Picard does not know about depends on the format, if possible Picard will store it as a free form tag. So your $set(Media Release Date,%date%) ends up in ID3 as TXXX:Media Release Date, in MP4 as ----:com.apple.iTunes:Media Release Date and in Vorbis / FLAC as MEDIA RELEASE DATE (Vorbis tags are case-insensitive, but get normalized to all uppercase on saving); and not at all for WMA.

For ID3 and MP4 the tags are case-sensitive, but Picard will read freeform tags back all lowercase but preserve the casing when writing back the value.

3 Likes

Thank you, @outsidecontext. That was very helpful.

2 Likes