# Discogs Album Artwork Failure

**URL:** https://community.mp3tag.de/t/discogs-album-artwork-failure/71409
**Category:** Support
**Created:** [June 7, 2026, 6:28pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409 "2026-06-07T18:28:03Z")
**Posts on this page:** 14
**Page:** 1

<div class="post-metadata">

### Author: ![kennethdotsey21](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/k/e19adc/32.png) [@kennethdotsey21](https://community.mp3tag.de/u/kennethdotsey21)
#### Post date: [June 7, 2026, 6:28pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/1 "2026-06-07T18:28:04Z")

</div>

Search album artwork click on the desired album cover or even numerous album cover offerings and get a blank album cover even though it shows when searching the actual album cover. I've been using discogs now

---

<div class="post-metadata">

### Author: ![spinner410](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/97f17d/32.png) [@spinner410](https://community.mp3tag.de/u/spinner410)
#### Post date: [June 7, 2026, 8:40pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/2 "2026-06-07T20:40:36Z")

</div>

Same here, super annoying. No album art preview when match, does not pull down artwork, etc, etc, etc.

I completely redid my authentication with Discogs 3 times, updated and reinstalled.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 7, 2026, 8:49pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/3 "2026-06-07T20:49:30Z")

</div>

For both of you: you would get much better responses if you followed:

> [@Hints for asking Support Requests](https://community.mp3tag.de/t/hints-for-asking-support-requests/56190):
>
> If you need support using Mp3tag, you can help the community members that are about to support you in finding a solution or workaround to your problem, by following these simple guidelines. Be descriptive, also in what you’ve already tried Please give a short explanation what’s not working as expected or what you’re trying to achieve. It’s best to know any details about the problem at hand and especially, what steps you’ve already tried to solve it by yourself. Helpful information also includ…

---

<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: [June 7, 2026, 9:30pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/4 "2026-06-07T21:30:27Z")

</div>

> [@kennethdotsey21](#):
>
> Search album artwork click on the desired album cover or even numerous album cover offerings and get a blank album cover even though it shows when searching the actual album cover. I've been using discogs now

> [@spinner410](#):
>
> Same here, super annoying. No album art preview when match, does not pull down artwork, etc, etc, etc.

Mp3Tag retrieves album info (including artwork) via dedicated scripts for each of the plethora of online databases; some come preinstalled with the application, while others are provided by the community.

If you need help getting your artwork to show, you'll need to share which script you're using (the name of the script you select in the "Tag sources" menu). And if you're using a community-provided script, please name the source\author.

Without this info, it's nearly impossible to figure out how to best provide support for each of your issues.

---

<div class="post-metadata">

### Author: ![spinner410](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/97f17d/32.png) [@spinner410](https://community.mp3tag.de/u/spinner410)
#### Post date: [June 7, 2026, 9:42pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/5 "2026-06-07T21:42:28Z")

</div>

i immediately edited my post to include Discogs as the source issue earlier.

---

<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: [June 7, 2026, 11:09pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/6 "2026-06-07T23:09:23Z")

</div>

There are community-submitted modded (and original) versions of the Discogs script that ships with Mp3Tag, so it was relevant to ask which version (vanilla or another) you were referring to.

On a fresh (portable) install of the latest beta, using stock Discogs script I can get results (after authorization):

 ![imagem](https://community.mp3tag.de/uploads/default/original/3X/a/6/a61f32be49db0da7d0411b78c63f7cd994752a91.png)

Preview covers are working fine, on result covers I'm getting some ocasional misses.

Discogs scripts aren't really my specialty, so I can't really offer much insight other than general troubleshooting tips:

- Check if the issue is general, or specific to (a) particular album(s);
- Discard local connectivity issues;
- Check site availability;
- (if possible) test on another machine/install.

Also, to better help the author, can you share if the system where you're having issues is MacOS or Windows?  
OS version could also be important.

---

<div class="post-metadata">

### Author: ![spinner410](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/97f17d/32.png) [@spinner410](https://community.mp3tag.de/u/spinner410)
#### Post date: [June 7, 2026, 11:43pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/7 "2026-06-07T23:43:04Z")

</div>

I am using a plain jane install on Windows 11. I have no add ins or plug ins. This started yesterday out of the blue. It is happening 99 percent of the time and I replicated it myself on another PC earlier today. It only happens when using Discogs as a source. It doesn't not happen when using Musicbrainz.

There is an entire thread on Reddit about it. It's not just me.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [June 7, 2026, 11:54pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/8 "2026-06-07T23:54:04Z")

</div>

> [@spinner410](#):
>
> This started yesterday out of the blue. It is happening 99 percent of the time and I replicated it myself on another PC earlier today.

If there were no changes to your OS or mp3tag, then the only other variable would be the Discogs site. Perhaps they made a change to their security.

> [@spinner410](#):
>
> There is an entire thread on Reddit about it.

Perhaps share a link for this reference?

---

<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: [June 8, 2026, 1:50am UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/9 "2026-06-08T01:50:08Z")

</div>

Ok, I might have found something interesting.

I've added debug info output to a copy of Discogs script, and found a few instances where cover art wasn't showing BUT preview cover art was fine.

Normally both images come from the same source; however the full sized cover art is sourced from a cached archive of Discogs, managed by the developer (I think), and the host `https://cache.mp3tag.de` is not currently accessible in my location, which could explain this issue.

@Florian may I trouble you to check this?

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 8, 2026, 5:50am UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/10 "2026-06-08T05:50:13Z")

</div>

The file system on the server ran out of inodes (\> 39000000). I just fixed the issue and everything should be back to normal.

Thanks for reporting!

---

<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: [June 8, 2026, 1:49pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/11 "2026-06-08T13:49:26Z")

</div>

Thanks! 👍

On a side note, I still can't open a cover URL in my browser. Yesterday I assumed there was something wrong with the server, but given that everything is working fine via Mp3Tag now (at least on my end), even if browser access isn't allowed, I was expecting some form of error page (404 or 403), but it's still not connecting to the host (although pings are sucessful).

Merely out of curiosity, is this the normal behavior?

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 8, 2026, 4:01pm UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/12 "2026-06-08T16:01:47Z")

</div>

Yes, it's the normal behaviour if you access this URL via a browser that enforces HTTPS. The server serves HTTP only, so you'd need to access via other means.

However, the server was still operational for all cached versions of images, but couldn't store and serve any new images that were not cached yet.

I'm always monitoring the available disk space of this server (it's already at 600GB), running out of inodes was something new.

---

<div class="post-metadata">

### Author: ![Casual\_Tea](https://community.mp3tag.de/user_avatar/community.mp3tag.de/casual_tea/32/18886_2.png) [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [June 9, 2026, 6:18am UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/13 "2026-06-09T06:18:14Z")

</div>

> [@Florian](#):
>
> I'm always monitoring the available disk space of this server (it's already at 600GB), running out of inodes was something new.

Same happened to me on my proxmox host a couple of years ago. A docker container had a date-related bug and created 100+ empty log files per second until no new files could be created due to a lack of inodes while 40gb of space remained free.  
I think learning about `df -i` rarely happens voluntarily.

Also funny was that I could not even delete the logs via `rm *.log` because that hit the argument limit. I had to write a loop with `find` to delete each individual log file instead. That was a pain in the butt.

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [June 16, 2026, 6:19am UTC](https://community.mp3tag.de/t/discogs-album-artwork-failure/71409/14 "2026-06-16T06:19:13Z")

</div>

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
