Hello everyone in the community.
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.
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?
It's displayed as track 1 on Windows and Mac here. Can you double-check again?
Well, this is interesting......
- 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  of the array, whereas in the raw data (in Firefox or .txt file) it's in position .
Also, opening the same link on online JSON parsers
will also show "Collision Course" in object .
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.
_pone_album_input.txt (12.4 KB)
I'll try to gather more data and edit this post with my findings.
You might recall this previous exchange
Checking 390849614 again:
tracks are 1-2-3-4
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
my (current) script:
- object  has track 3, as does my script, but in the raw data object  has track 1.
Disclaimer: apologies for the explicit content of the pictures. I have no ill intent towards anyone in the community with this post.
Can you try changing
[AlbumUrl] to use
https:// and see if it makes a difference for you?
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
[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.