No hurry. I’d probably put it somewhere easily visible. Edit notes are usually the last place I’d look, although sometimes when I intent a more complex edit, reread it and then think “what the fuck am I doing?”
When importing images sometimes the same image is queued twice I guess it’s due to mouse problems. Got a clue, might actually be related to CTRL+ Click (I open multiple releases in advance and prepare images as I CTRL+Tab through them)
Edit note text doesn’t get duplicated though. Usually I remove it from the form but at least one time I missed it:
Trivia:
Even before the script supported Qobuz I noticed that for a few releases the API returns 404 even though the release is still visible in the shop at least in the linked locale.
Another fresh example from the forum
Bandcamp track images are sometimes used unorthodoxically:
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.
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:
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.
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.
Image Max URL required a bugfix for the upcoming Violentmonkey release:
There seems to be some URL decoding trouble: 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
On a rare occasion I saw a 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
Display CAA image dimensions
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”:
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.
