[WS] iTunes source script with multiple search criteria

[rboss]

@Florian

I'm not sure if we talked about that before, but each of the multi-value fields where values are separated by the pipe symbol | need to have a trailing |. Say "|" after filling each of those fields should serve as an easy fix.

I do recall a previous topic (of mine) where a missing trailing pipe symbol was causing issues. At the time, the solution was provided by you:

@Florian

I've analyzed the issue and it's related to a certain — until now undocumented — requirement by Mp3tag's internal tokenizer which splits a string using | as delimiters into its separate parts. It always expects a trailing delimiter character and if not present, adds it by itself.

Is this what you meant? If so, I was under the impression that the "|" character was only 'necessary' in cases where a multi-value field was missing the last entry of its set, and a Say "|" command would provide the final pipe as to not cause the internal tokenizer to behave unexpectedly. In fully loaded multi-value fields the issue would not occur, and the command for the final pipe was merely optional.

I had already fixed that in my script version 350,

@rboss

Thanks to Florian for his revised documentation of JSON tools, the previous patch has now been worked into a permanent fix. In the rare event that a censored dataset is incomplete, the script will now try to fill any gaps with uncensored data, or return an empty tag if none is found, preventing the propagation of incorrect results.

and without any feedback of issues under macOS, was assuming everything was working fine in that front. And under Windows it is as my screenshot showed -all tracks correctly parsed.

I'm aware that the performance impact is virtually zero, but as I keep trying to make my script(s) as efficient as I am able to, if a trailing "|" is not 'necessary' for normal operation I prefer to avoid using it. At the time, because the iTunes' advisory tag was prone to have missing values, the Say "|" was added (and is still present in v362). Since the other tags were completely filled, I considered a trailing pipe as non-essential and didn't add it.

Of course, if this is a macOS-only requirement then I will happily oblige, for the sake of compatibility (and keep it in mind form here on out).

@thick.crew Apologies for the delay. As you can guess from this exchange between myself and the developer, I don't own a macOS system, and thus am unable to test \ validate my script to work in it. So I have to rely on kind community members to run those tests, and it's not the first time I've had to play a game of 'telephone' with @Florian, where he instructs me what is wrong, I (try to) make the necessary fixes, and reply with a new (hopefully correct) revision that works under macOS. I do try to make changes that work in both OS's, but for Mac, I'm literally guessing and hoping for the best.

In this instance, as @Florian described, the 'quick patch' to restore iTunes API functionality is to add the aforementioned command where necessary. Which should be done in this beta:

iTunes WS#364_[US] - [English]_beta.src (14.7 KB)

As for Apple Music mode, some reworking of that part of the script will be required, and will take some time (plus some new planned features for the script). I prefer to release a half-working beta script now, than a fully working script, but not knowing when it would be finished.

So, please give this beta a try, and see if 'iTunes API' mode is working normally. Because the issue you reported didn't manifest under Windows, the fix also doesn't show any difference in results on my system.

@Florian if the pipe symbol requirement for Mac was mentioned elsewhere, could you direct me to that topic please? Given its importance, I'd like to get as much information about it as I can. And if @thick.crew, yourself, or anyone else in the community could provide feedback on this beta, I would appreciate it, and update the first post with this version.

And Thank You