I'm hoping someone can enlighten me on an odd behavior when parsing JSON data. More specifically, on how objects in an array are sorted when being parsed.
Example:
this link will download raw JSON-formatted data for an album in iTunes. In the results array, the 2nd object (a track called "Collision Course") refers to a music video. So, if using a WS script for iTunes (like pone's) and querying this album (id 185731554), then track 1 should have the info for "Collision Course". But this title is displayed for track 7 (the last).
The same thing happens if the same link is opened on an online JSON reader. Some sites will render and sort the objects in the same order as they appear in the raw data, while others (like Mp3Tag) will move the object with the data for "Collision Course" to the last position.
So, this is not a bug in the tagger, but since the raw data has no (visible) index in the objects, how/why is this happening?
Additional info:
- Mp3Tag 3.23 in portable mode, on a Windows 10 machine
- pone script unmodified
- print screen(s) are unmodified
I'm reading the raw data in Firefox 119.0.1 in view-source:https://itunes.apple.com/lookup?country=US&entity=song&limit=200&id=185731554. Downloading the file (as .txt) and opening it in Notepad shows the same data as the URL.
If I modify pone's script and enable DebugWriteInput I get a file (attached), which (in my case) has the music-video object in the last position [7] of the array, whereas in the raw data (in Firefox or .txt file) it's in position [2].
Also, opening the same link on online JSON parsers https://jsoneditoronline.org/ https://jsonformatter.org/json-viewer
Again, I don't believe this is an Mp3Tag issue since it also happens externally. I'm just posting here because the behavior was found while using Mp3Tag.
Please disregard the track 'numbers'; what is important here is the order of track titles.
By the raw data, the 'Lyric Video' is tracknumber 4, and is the last object in the array of raw data
It does.
I was assuming (incorrectly) that the raw data in the browser (1-2-3-4) and in DebugWriteInput (2-1-3-4) were the same dataset when they were in fact 2 different datasets (with the same data, but sorted differently).
And because I double-checked using pone's script for comparison, which also uses http:// instead of https:// in [IndexUrl] and [AlbumUrl], I was making the same mistake again. As per the album page, "Collision Course" is %tracknumber% 7; but because his script doesn't parse track numbers, Mp3Tag assigns %tracknumber% 1 to the first track entry in the raw data, regardless if it corresponds to the real Track 1 or not, which added to my confusion.
So this topic was a case of human error from my part. Apologies.
--
I opened a topic with a question to the community. The question was answered by the community. Thank you Florian for your time and patience. From my part this topic can now be considered answered/solved and closed.
