The debug output file from the websource script language command debug "on" "debug.out" doesn't always contain the correct script line numbers, instead the shown numbers usually are smaller. This makes it difficult to debug a script, because the line numbers given are not reliable.
To show this, I added the above debug command to the script file Discogs Release ID.src and made the following two pictures:
The part for the coverurl between lines 63 and 81 finds a primary image in the first run and a secondary in the second. From the below picture you see, that the line numbers are correct (green marked) in first pass and wrong (red line) in the second. The difference is 50 lines.
I can't find any issue on my end.
After looking at your screenshots and replicating the test on my system, the Discogs Release ID.src script seems to be doing what it should. I cannot cause the loop to break and jump to L20 (as pointed by your lines in red)
Have you modified the Discogs Release ID.src beyond enabling debut output?
Also, to discard any issues with the data source, would you mind sharing the Discogs' release id used for your screenshots?
I can't either, and I did not even mean that. All I wanted to say, is that the script correctly executes the lines 74 to 78 and the debug output incorrectly tells us, the line numbers were 20 to 24, which are actually lines from the comment block at the top of the script. To make it clear, the script runs OK, all that is wrong, are a few line numbers in the debug output in that particular place. And it happens with all discogs releases I tried so far, that contain at least two images, a primary and a secondary, for example http://www.discogs.com/release/3082982.
That's the information that was missing.
By using your example link, I can now replicate the behavior. It is very odd; but I also noticed something else.
The image (primary + secondary) links are redirected to the cache.mp3tag.de domain instead of discogs.com.
This is merely me guessing, but if the developer is able to host the cover art database from Discogs, then it wouldn't be too far-fetched to assume the internal source code of the Mp3Tag executable has some additional form of processing (image) data from that source, beyond the WSS script, and the line-numbering bug could be a result of such.
But since I'm not the developer, I won't chase this particular rabbit down the metaphorical hole any more.
Even if my assumption is wrong, then your bug report will surely reach him, and eventually be evaluated.
Even if my assumption is right, the same will happen.
Thank you for fixing.
FYP I append two graphs showing on the x-axis the running counter of the script command executed, and on the y-axis the line number of the command as reported in the debug output protocol. The first graph shows the situation before the fix with isolated blue stains of wrong line numbers below the correct numbers.
You see that all line numbers are following each other in ascending order, except naturally for the json_foreach loops. There are no runaways any more.
