# Incorrect script line numbers in debug output
**URL:** https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [October 2, 2024, 5:04pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132 "2024-10-02T17:04:19Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [October 2, 2024, 5:04pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/1 "2024-10-02T17:04:19Z")
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.
And yes, I love colored source code.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [October 6, 2024, 1:39pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/2 "2024-10-06T13:39:54Z")
> [@yorickausyps](#):
>
> 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.
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?
---
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [October 6, 2024, 7:30pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/3 "2024-10-06T19:30:48Z")
> [@rboss](#):
>
> I cannot cause the loop to break and jump to L20 (as pointed by your lines in red)
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](http://www.discogs.com/release/3082982).
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [October 6, 2024, 11:14pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/4 "2024-10-06T23:14:39Z")
> [@yorickausyps](#):
>
> And it happens with all discogs releases I tried so far, that contain at least two images, a primary and a secondary
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](http://cache.mp3tag.de) domain instead of [discogs.com](http://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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [October 10, 2024, 2:18pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/5 "2024-10-10T14:18:44Z")
Thank you for reporting! I've fixed the issue with [Mp3tag v3.27c](https://community.mp3tag.de/t/455).
---
### Author:  [@yorickausyps](https://community.mp3tag.de/u/yorickausyps)
#### Post date: [October 10, 2024, 4:51pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/6 "2024-10-10T16:51:01Z")
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.
And now with the fix the same graph looks like this:
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.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [November 9, 2024, 4:51pm UTC](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132/7 "2024-11-09T16:51:40Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.