Thanks again for all of those reports! I don’t think we can do much about the Bandcamp track image issue except for “Fetch front image only” and some better previewing utilities on the cover art upload page (which will get added eventually, promised!), but I’ll see what I can do about the rest.
A bit of good news: The script will now grab the original source images for Apple Music releases 
Still loooooooooooooving this script! Thought I’d reiterate my request from earlier, but this time with two possible ideas. This relates to removing the pointless click + wait for ‘this release has no cover art’ page to load, then click again to add cover.
When album has no cover, make ‘cover art’ tab go straight to 'add cover art page:
(yes, MB inline script does this but I’m not using it ATM)
Put the import links on the ‘Cover Art’ page, so the process can be started from there directly:
When album has no cover, make ‘cover art’ tab go straight to 'add cover art page: (yes, MB inline script does this but I’m not using it ATM)
Since it’s already covered by another script, I’d prefer not to conflict with it. The other idea is viable, thanks!
Another reason I prefer option 2 over option 1 is that option 2 will save a click even when there are existing covers already.
Would you be so kind to link it? It would be such a time saver, but I’ve never stumbled upon this one.
If I’m not mistaken, it’s “MB. INLINE STUFF” by @jesus2099: https://github.com/jesus2099/konami-command/raw/master/mb_INLINE-STUFF.user.js
I’m not sure what to do with these, because it’s sort of hitting the point of diminishing returns. As you said, there are a lot of possible marketplaces that could be added, and each one of them takes time upfront to implement, in addition to time spent maintaining them when their websites change. As much as I’d like to implement support for every possible website, it’s probably better to limit the scope somehow to avoid ending up with an unmaintainable or unmaintained mess, especially since we can input image URLs directly. I’m not quite sure what the cutoff would be, though.
I’ve also been thinking about a sort of “generic” provider that would try to extract the image(s) from any webpage using some heuristics. But as I commented in that thread, I’m not sure whether that’s a good idea either.
For some time now I’ve been seeing Failed to grab images: Apple Music release does not exist for some Apple Music links even though the release clearly exists.
So far this only happens when logged in to an Apple Music account.
The script by @Toad_King seems to be affected similarly. On Apple Music pages where the cover upload script fails I see:
TypeError: Cannot read properties of null (reading 'innerHTML')
I already have a clue what might be causing it but am curious if anyone else has experienced it.
i have experienced this a few times as well, though i haven’t been able to find a pattern. it happens maybe 5% of the time for me
Can you link to an album on Apple Music where it fails? I tried it on the edit you linked to in your post but it works there for me.
This one failed a couple times (reloading the page):
https://music.apple.com/de/album/930959393
When logged out it seems to work all the time. I suspect it’s related to parental controls. When I have them enabled with everything allowed the scripts have no trouble:
Once I disable parental controls (content restrictions toggled off) sometimes the scripts fail. The cover uploader script appears to be more susceptible to this.
Hmm, I can’t seem to easily reproduce this on Chrome (and I can’t log in to Apple Music on Firefox at all), but if it really is the case that this only happens when you’re logged in, it should be possible to devise a workaround for the cover art uploader.
https://archive.org/details/skd815
Followed redirect of https://ia903101.us.archive.org/33/items/skd815/#cover.jpg -> https://ia903101.us.archive.org/33/items/skd815/ while fetching image contents
Skipping maximised candidate https://ia903101.us.archive.org/33/items/skd815/#cover.jpg: Expected to receive an image, but received text. Perhaps this provider is not supported yet?
Followed redirect of https://ia903101.us.archive.org/33/items/skd815/#cover.jpg -> https://ia903101.us.archive.org/33/items/skd815/ while fetching image contents
Skipping https://ia903101.us.archive.org/33/items/skd815/#cover.jpg: Expected to receive an image, but received text. Perhaps this provider is not supported yet?
The actual image is at https://archive.org/download/skd815/%23cover.jpg
429 from Apple. This caused the link for cover art seeding not to be added. Perhaps the script could gracefully retry or show a manual retry option?https://atisket.pulsewidth.org.uk/?spf_id=1WRqanANwPz8JyH0p78IPh
9999x9999-100.jpg:1 Failed to load resource: the server responded with a status of 429 ()
MB： Enhanced Cover Art Uploads.user.js:105074 [mb_enhanced_cover_art_uploads] Failed to add seed links to some cover art
onError @ MB： Enhanced Cover Art Uploads.user.js:105074
I don’t remember if it ever worked in either case but on “set cover art” pages neither dimension nor size are displayed and on release group pages size is always “??? KB”:
https://musicbrainz.org/release-group/e722cfc7-0975-4a33-82dd-bf37cc714321https://musicbrainz.org/release-group/ab26a2e1-76bf-4007-ac86-8f064d456a8a/set-cover-art5: 'Withdrawn',
6: 'Cancelled',
21: 'SnapPack',
54: 'Metal Tin',
55: 'Longbox',
If you’re making changes I have a small request - Could resized Bandcamp covers be put before the non-square ones?
In the past I wasn’t sure about putting them on releases at all, but over time I’ve come to realise that since these are what’s displayed on Bandcamp pages, as well as in the download files/in your player, it’s Bandcamp’s intention for them to be the ‘primary’ cover.
The full size weird ratio ones are more like the bonus extra imo. Opinions may differ!
I personally think the opposite, as the artist (or sometimes label) uploaded non-square artwork, therefore I think artist intent may apply. in fact I’ve added one or two albums with a square crop (from Spotify) and only added the full size from their website. (actually, after checking, I didn’t actually add the streaming release… to a-tisket!)
that said, if it were somehow toggleable, I’d be down with that~
Ooh, this would be a rare no-vote from me if it had come up in one of my subscriptions! 
If it was based on a iTunes/Spotify etc release, anway. After all, we track release-specific imagery. So if it didn’t come with the release…
My thinking is, these days, that Bandcamp lets you upload non-square images because it’s happy to square it up for you. It then displays a cropped/square cover everywhere where it matters. MB displaying non-cropped would be an outlier in this case. An extra click in Bandcamp gets you the non-cropped original, which we can replicate in MB by having the picture second.
It didn’t take long for the next bug to reveal itself using Violentmonkey BETA 2.13.0.19
Failed to enqueue some images: Could not find image a0273152139_0.0.png in queued uploads
Successfully added 1 image(s)
instrument.js:102 [mb_enhanced_cover_art_uploads] Searching for images in Bandcamp release…
instrument.js:102 [mb_enhanced_cover_art_uploads] Found 1 image(s) in Bandcamp release
instrument.js:102 [mb_enhanced_cover_art_uploads] Fetching https://f4.bcbits.com/img/a0273152139_10.jpg (1/1)
instrument.js:102 [mb_enhanced_cover_art_uploads] Maximised https://f4.bcbits.com/img/a0273152139_10.jpg to https://f4.bcbits.com/img/a0273152139_0.jpg
instrument.js:102 [mb_enhanced_cover_art_uploads] Failed to enqueue some images Error: Could not find image a0273152139_0.0.png in queued uploads
at assert (MB： Enhanced Cover Art Uploads.user.js:106014:4515)
at assertDefined (MB： Enhanced Cover Art Uploads.user.js:106014:4592)
at setImageParameters (MB： Enhanced Cover Art Uploads.user.js:108139:5)
at _catch (MB： Enhanced Cover Art Uploads.user.js:106011:5950)
at MB： Enhanced Cover Art Uploads.user.js:106014:9916
at MB： Enhanced Cover Art Uploads.user.js:106011:3654
at MB： Enhanced Cover Art Uploads.user.js:106014:9985
at async Promise.all (/release/d21b249f-1770-4af3-9fad-8f5752a82b04/index 0)
(anonymous) @ instrument.js:102
onError @ MB： Enhanced Cover Art Uploads.user.js:106014
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:106014
fireHandlers @ MB： Enhanced Cover Art Uploads.user.js:106014
error @ MB： Enhanced Cover Art Uploads.user.js:106014
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108528
Promise.then (async)
_catch @ MB： Enhanced Cover Art Uploads.user.js:106011
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108525
t @ MB： Enhanced Cover Art Uploads.user.js:106011
_forOf @ MB： Enhanced Cover Art Uploads.user.js:106011
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108520
Promise.then (async)
_continue @ MB： Enhanced Cover Art Uploads.user.js:106011
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108508
_call @ MB： Enhanced Cover Art Uploads.user.js:106011
processSeedingParameters @ MB： Enhanced Cover Art Uploads.user.js:108504
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108869
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108879
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:108880
window.VMina7ijceh13uhapolm @ MB： Enhanced Cover Art Uploads.user.js:108880
i @ injected-web.js:1
Vt @ injected-web.js:1
set @ injected-web.js:1
(anonymous) @ MB： Enhanced Cover Art Uploads.user.js:1
pt @ VM309 injected.js:1
mt @ VM309 injected.js:1
await in mt (async)
ft @ VM309 injected.js:1
ut @ VM309 injected.js:1
await in ut (async)
(anonymous) @ VM309 injected.js:1
await in (anonymous) (async)
(anonymous) @ VM309 injected.js:1
Re @ VM309 injected.js:1
dt @ VM309 injected.js:1
qt @ VM309 injected.js:1
await in qt (async)
(anonymous) @ VM309 injected.js:1
n @ VM309 injected.js:1
(anonymous) @ VM309 injected.js:1
(anonymous) @ VM309 injected.js:1
instrument.js:102 [mb_enhanced_cover_art_uploads] Successfully added 1 image(s)
As you have probably already noticed, we have merged a PR with the low hanging fruit improvements and the fix for the URL encoding issue:
For the remaining suggestions and bug reports I have created a few tickets, thanks for reporting:
So I’ve been debugging this issue with Violentmonkey Beta for a couple of hours now, turns out it’s not an issue with the cover art uploader itself. I’ll spare you most of the technical details (check the Github issue to know more) but it boils down to a conflict between ECAU and some other script (could be any installed script). There’s unfortunately no way to reliably fix this issue, but I’ll see what I can do. Even if I manage to fix it on my end, it’s still possible that you have some conflict-causing userscript installed which I don’t.
Edit: I fixed my scripts to prevent this. For me, Supercharged Cover Art Edits was causing the conflict, so that might do the trick for you too.