# 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:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@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")

</div>

> [@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.

---

_[View the full topic](https://community.mp3tag.de/t/incorrect-script-line-numbers-in-debug-output/66132)._