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.
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.
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:
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.
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:
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.
Also, thank you for all your help, @rdswift. I’m still untangling the scripting part of Picard.
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.
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.
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.