Display cover arts in MusicBrainz pages: “mb. FUNKEY ILLUSTRATED RECORDS”

Tags: #<Tag:0x00007f7d01e37e68> #<Tag:0x00007f7d01e37d78> #<Tag:0x00007f7d01e37918>

Thanks so much for this one @jesus2099, I use it all the time (just the inline images), and it’s what encourages me to add cover art :slight_smile:

2 Likes

Nice. Look very small on the Collection pages, sadly. But thanks for the work.

Hope it will give ideas fo a native implementation in the near future…

Thanks again and for the thread creation.

1 Like

@jesus2099 first of all: thanks, for this and many other great scripts. :+1:

My question is: Would it be possible to display the cover art in release merges too? It is being displayed in many other types of edits, where I don’t always see the sense, but for release merges it would be really helpful. After all different cover art is a reason not to merge even if everything else looks the same.

4 Likes

You are right, Paula: https://github.com/jesus2099/konami-command/issues/435

2 Likes

@jesus2099 I really love this userscript and wondered why the cover art shows up for edits only on some pages (e.g. entity pages for edits and open edits) and not everywhere (on user’s edit and open edit pages). To solve this, I’ve temporarily added an additional match line

@match *://*.musicbrainz.org/user/*/edits*

to the script – there might be better ways to implement this :innocent:

Is there a particular reason these pages were not matched or is this just something nobody has ever requested? I often check edits of editors in batch from their pages and it would really help me if you could integrate this – not only for this script but also for e.g. the duplicate ISRC highlighting (I don’t know which script ATM).

Edit: I’ve successfully added the following line to both mb. FUNKEY ILLUSTRATED RECORDS and mb. INLINE STUFF:

@include /^https?://(\w+\.mbsandbox|(\w+\.)?musicbrainz)\.org/user/[^/]+/edits[/open]?/
2 Likes

There is no particular reason indeed.
I don’t really use user edit history, that’s why. :wink:
I have added your request as part of Fix edit list page display.

4 Likes

I wonder if it would be possible to display a small release icon (like on the release-goup pages in front of the releases) on the work pages in front of the recording titles ?

Take for example the following work page of Springsteen’s “Born to Run”:

There are literally more than 1000 entries coming from different live bootlegs. Would be nice to see to which release they belong

1 Like

It would not be trivial because each recording may itself be on several releases.
We could not display that many icons all over the place without making it completely unusable, no? :woozy_face:

1 Like

Oops, you are right, I forgot about hat fact…

Not even as an user option ?

We should first need a Release column (and maybe an ISRC column) like in recording search page.

Then…

Sorry but I’m pretty sure I wouldn’t have time to work on it, having some other features that I would like first in my big backlog. :bowing_man:

It’s stopped generating new little thumbnails for some of the releases? Which is weird, is that a CAA issue?

I miss my little pics :heart:

Also I’m not sure what everyone’s preferences are, but I always turn off big images… if others usually also do then it would be great if the script could load with them off, esp when it updates :slight_smile:

1 Like

Are you using most recent version?

I disabled small pics when MBS introduced a CAA icon but now I enabled it again, but I am now using those MBS CAA icons.

They are smaller than the old small pics but integrate better in the site.

Saving your settings (big pics = false), it would be nice indeed. I will think of it. :slight_smile:

1 Like

Version looks to be the one on Github (2020.9.2.1710).

This is an example of where newer icons aren’t loading - I’m guessing the CAA is catching up or something? I wasn’t aware that the CAA was now generating them fully, or maybe I forgot :o


I deactivated the big pics to match your setup.

With this last version should display these (very) small pics, which link to the release cover art tab.

These very small pics are added by the script in this artist page and are replacing the plain icons in release group page.

1 Like

@aerozol, what do you think now that they are very small pics?

Should I restore the small pics enlarge on more hover or mouse click?

Knowing that the 250px thumbnails are already loaded in memory, ready to be displayed fully.

:heart:
I’m not seeing a newer version to download at Konami Kommand?

I like it with clicking > cover art pages/like it is now. I don’t need anything fancy like rollover to be honest, I personally just want a little visual representation of what is missing art (+ it looks nice).

Anby idea why some of those RG’s, like the Gold Edition Soundtrack, aren’t getting icons?

1 Like

Does it now works for you like on my screen capture?

Oh indeed, this release group which has a release with front cover does not show it.

It must be because of the pending edits (moderation pending) orange background mark span.mp I’ll fix that.


I found that this front cover art is still pending.

Because I know that if a release has a removed front cover or a voted down front cover, those are still in the cover art archive.

This is why I check that the front cover art is approved before showing it.
But maybe it’s silly.

I want to find a release with voted down and removed front cover to make sure I can remove this check so that pending front cover art edits can be shown.


I could check a removed front cover art:

The image is still in the CAA but the release-group API returns a Not Found 404 Error :white_check_mark:


I could check a voted down front cover art:

The image is still in the CAA but the release-group API returns a Not Found 404 Error :white_check_mark:


I can remove my useless check to include pending edits.

2 Likes

Ah maybe I wasn’t clear, it was always working like in your screen capture. And now it works for pending edits too!! That’s what I thought was broken!

In my opinion you can remove the check for pending edits… if it’s wrong/a removed cover hopefully someone will be encouraged to upload the correct one for the RG.

The updated script still has: var bigpics = true;
Which I always change to false :slight_smile:

2 Likes

I am sorry to say @jesus2099 but with one of the latest updates you must have broken something: On pages with many release groups not all cover art is loading anymore. I am using both the big pictures and the small pictures and today I have encountered two strange behaviours of your script that I have not seen before:

  1. Every time the page is reloaded different release groups are affected by missing cover art (browser console has a mix of 503 and CORS errors).
  2. Some release groups show both the small inline pictures and the big ones on top of the page, some display only one of them, some are missing both.

I did not have a look at the code yet, but maybe you are querying the CAA twice for each picture in the newer versions and this causes (some of) the problems? For debugging I can recommend this series as a test case which has over a hundred release groups with numbers on their covers, so it is very easy to spot the missing pictures :wink:

Hi @kellnerd, thanks for the other regression report in github.
For this one, it looks related to what I’ve seen on some smaller lists:

It’s since I tried to make a cleaner script that uses CAA API instead of brutally trying all image loadings.
Maybe this ticket will fix your issue too. I’ll check that.

3 Likes