Apparently there's been some (undocumented) changes to the iTunes API, which causes searching for an Apple collection ID to no longer return results.
This means that this feature:
is currently not working.
I've struck out this string of text in the first post for the time being, and I'll keep looking into this issue; if it sorts itself out - fine; if not I'll try to patch my script to re-enable ID search.
It has been a couple of weeks, and searching for an collection ID still returns nothing, so I will assume from now on that the change is permanent.
In retrospective, this type of search was always a fluke: searching via ID number is possible yes, but uses a different call to the API (a lookup, instead of a search). So using an ID in a keyword search was never guaranteed to yield results. To have as long as it did has been an stroke of luck.
Work is already underway into trying to add ID lookup as well as keyword search on this script, but with the time I can spare to this endeavor, a new version should not be ready by the end of this year.
As a silver lining, ID lookup is well documented, so if/when I get it working, it should be relatively stable (hopefully ).
As for the first post, the struck out text regarding id search will remain as such, as I consider it an important feature of my script(s), and plan to (eventually) restore this functionality.
Here is a quick patch to fix the recent change to the JSON data structure in Apple Music mode; v3.72-stable.
v371 > v372 change log:
Fixed \ Changed:
'Apple Music' mode fixed to comply to the new JSON data structure of the source;
Please use the link below; I won't be updating the first post this time (for now), since the new major revision (still a WIP) will probably bring about a large review of that post.
For those who use the beta releases of Mp3Tag, since 3.36-beta.3 a change to how JSON data is processed
has partially broken the workflow of my script, in the section responsible for filling the ITUNESARTISTID tag.
Specifically, when the track artist was lacking their respective id(s) in the source data, the id value of the Album Artist was used to fill the missing value(s). Since 3.36b3 this no longer happens; and only those ids present in the source data are returned.
At the time of release, I didn't realize the impact of the fix in my WSS; but while working on the new version it became apparent (and is already corrected).
I'm aware of this issue, but currently I'm prioritizing work on the new build. If I can release it within the next couple of weeks, there will be no need for a patch; if not I'll release a quick-fixed version to address this issue.
Again, only since Mp3Tag 3.36-beta.3 does this behavior occur (and only using the source Apple Music); on the current stable version my WSS v3.72 works fine.
Unfortunately, it will be the latter; as I haven't been able to polish the new version to the point I feel is ready for release.
As such, the changelog for this version is:
v372 > v373 changelog:
Fixed \ Changed:
'Apple Music' mode adjusted to the new operation of the json_foreach command, first introduced in MP3Tag 3.36-beta.3
The patch was lifted from the new version of the script; and needed some tweaking to work in this build, so it's not 'the best' syntax to fix the issue, but it works (and it is stable). Using an example, on v372 the ITUNESARTISTID column would include blanks, like