Mp3tag version 3.22 - json_select_many function

Bug Reports
1

Hello everyone,

I think there is a bug with version 3.22, on the json_select_many function. I'll try to explain in detail:

  • using my own script to parse json formatted data from iTunes API, on [ParserScriptAlbum] I use json_select_many to get the "contentAdvisoryRating" value for each track, which classifies it as explicit or not. It's important to note that the "contentAdvisoryRating" key is only present if that track is considered explicit and absent if it is not. In a simple example, the raw data from the API would be something like:

{"wrapperType":"track", "trackName":"one", "trackNumber":1, "contentAdvisoryRating":"Explicit"},
{"wrapperType":"track", "trackName":"two", "trackNumber":2},
{"wrapperType":"track", "trackName":"three", "trackNumber":3},
{"wrapperType":"track", "trackName":"four", "trackNumber":4, "contentAdvisoryRating":"Explicit"},
{"wrapperType":"track", "trackName":"five", "trackNumber":5, "contentAdvisoryRating":"Explicit"},

where tracks 1, 4, 5 are explicit and 2, 3 are not. Again, what's important in this example is that in this json array, some elements have the "contentAdvisoryRating" key and some do not.

On version 3.21:
Using the command json_select_many "results" "contentAdvisoryRating" "|" the respective output for the above example would be:

output["TAG"]= Explicit | | | Explicit | Explicit

  • one "explicit" value followed by a separator " | " a "blank" value followed by a separator " | " another "blank" value followed by a separator " | " one "explicit" value followed by a separator " | " another "explicit" value >>>>> this is desired.

On version 3.22:
The same command on the same data outputs:

output["TAG"]= Explicit | Explicit | Explicit

  • one "explicit" value followed by " | " another "explicit" value followed by " | " and another "explicit" value >>>> this is NOT desired

This is just a simple example that represents the problem as I am able to identify it. From my understanding json_select_many is ignoring absent keys instead of assigning 'blank' values to the output. I'm also unsure if other json-related functions are also having troubles.

Can anyone else replicate this problem? Is it a bug?

Thank you.

2

Sorry to have caused this semantic change without documenting it correctly. It happened during the recent changes leading to v3.22 and the current behavior is, what the updated Beatport web source required.

I didn't think of the way you're using the command. I've noticed that you've already released a fixed version of your script. Does this include a working workaround for the issue described here or are you still looking for a solution?

3

Hello Florian,

as I mentioned in the notes for the fixed version, the issue will only occur if someone edits the script to enable the part of the code that uses the "trackCensoredName" key and for some reason the raw data 'skips' the key in one or more tracks. The 'skip' would be detected within the results of json_select_many by searching for a double separator, and an 'if' clause would switch to another method (json_foreach) for parsing the same keys.

So, for day-to-day use, it should be fine. But for development purposes, I am trying to find a more efficient workaround.

Then the new behavior of the json_select_many of skipping 'blank' values will be the default one? If so, I will need to make a proper fix; if not (and this is a bug to be corrected) I'll just wait for a solution from your end before committing changes to my own script.

As always, thank you for your time.

4

Can you share an example where the current implementation of json_select_many shows the issue you're describing?

I don't think that I can revert the current behavior of json_select_many back to include the blank values — it's already used too widely with the Beatport tag source.

But I thought about adding an extra parameter to the function to optionally include the blank values. This could then be used in the case you're describing.

5

Of course.

I normally use a "testbed" script to experiment with before making a clean and tidy version for release.
I'm sending you (via PM) a copy of that script, in which I hard-coded an iTunes id.

So if you run the script in both Mp3Tag 3.21 and 3.22, it should default to an example results page, and the issue with the contentAdvisoryRating key should become clear (I've outputted it to a 'Rating' field).

But since this is a test script not meant for public release, its quite untidy. Apologies in advance.

6

Many thanks for the helpful example script!

I've just released Mp3tag v3.22c, which adds the aforementioned additional parameter to json_select_many so that you can use something like

json_select_many "results" "contentAdvisoryRating" "|" "|" 1000 1

Hope this is what you were looking for.

7

Thank you very much for accommodating my request!

I'll get to it as soon as I'm able to do so.