If I can manage to wake up an admin we can turn this into a useful thread about userscripts.
On a Release page I also have things like “Set Recording Comments”. I do a lot of live bootleg editing and that lets me pop the same comments into each recording on the page without needing to open each recording one by one by hand.
Also “Compare AcoustIDs easier” is the one I think makes the numbers more visible and clickable. Especially handy when merging recordings.
I knew I had a proper link somewhere:
Go to bed !! whahahahahaha
We also need to find some one to make a import script for https://www.muziekweb.nl/
So who can we ask 
I’m having the same issue as OP. I’ve tried clearing my cookies (I don’t have a Discogs account so the log out/log in trick won’t work for me) but it doesn’t help. I haven’t been able to import any releases from Discogs since this started ~3 days ago.
I’m running Chrome on macOS 11.1, if it matters.
@HibiscusKazeneko - when logged out I can’t get the addon to work at all. As I have accounts on both I always assumed it was linked to being logged in.
When I currently look at one of my PCs on the logged out Discogs I also have a broken “do you want cookies” banner at the bottom of the page. Instead of displaying, it is just a grey lump. Think something else may have changed\broken at Discogs.
That page is so borked it isn’t even attempting to load the trackers and adverts. nothing noted in ublock origin or privacy badger.
The first time I open a Discogs page in any browser the page dims and I get the GDPR warning requiring me to accept. That was there before all this happened, and it still appears now.
I tested the site on Chrome (where I have uBlock Origin and Tampermonkey with scripts installed), Firefox (with no such extensions) and Safari (with even less; it even loads ads) and all 3 browsers loaded the grey box. On Safari, the grey box at the bottom contained an ad.
They probably screwed something up in their CSS that’s causing release pages to display improperly (and is interfering with third-party scripts). The only way out of this I see is if the import script is updated to account for Discogs’ CSS changes, as I doubt Discogs will be willing to accommodate us.
I get no GDPR warnings now in Vivaldi (chrome based). It does appear on Firefox (but no script there yet… will install shortly)
There is some very weird hacking around of their code going on lately. Sometimes when trying to login I get asked twice - once with a login page, and then with “login with google\faceace\apple account” page. One time it wanted a 2FA logon.
Whoever is editing their code at the moment is not having a fun time. So it will probably change again in a couple of days.
May need to ping @murdos to have a look at this, but it is likely to be a moving goalpost as Discogs will need to fix their webpage if it messed up their own advert delivery.
The place to get the scripts is now only GitHub - jesus2099/konami-command: power‐ups for various web sites.
I am abandoning the other places.
Strange, for me everything is working just fine as it always did with v2020.9.13.1 using Violentmonkey, although…
Furthermore I am not seeing any ads, grey boxes or the GDPR warning thanks to uBlock Origin and NoScript (for which I only whitelisted discogs.com and which is hence blocking a domain called cookielaw dot org).
The large image addon is great!
You can also paste image urls into this webpage if you don’t want to install an addon:
Sorry if someone already mentioned it and I missed it.
You may have missed a detail there. I also use uBlock Origin on both the example browsers, and the grey boxes appear when I am logged out. This morning my main browser is behaving “normally” again and showing the button when logged out. And a quick check and I think the other PC is now behaving as expected on logged out sessions. Pink dots and buttons are back (but still a big grey sploge on the right where an advert would be)
same here IvanDobsky
Welp, release pages are back to displaying normally for me. I guess Discogs must have sorted out whatever was messed up with their new code changes.
Same here. That was there (for me at least) before this whole mess started.
I just noticed a new difference since the import script started working again: it no longer consolidates medley tracks when importing a release. (Discogs stores medleys as individual sub-tracks on a medium.)
Me too. I also got caught out by that, but just assumed it was had always done that. As long as it is spotted quick the track list can be corrected, but you get stuck with orphaned recordings.
Can you give an example? Ideally an old import where consolidation worked as expected and a new import where it did not. I am curious because nothing significant has changed recently (see last commit messages):
… there only is a pull request to achieve this (IMO undesired) behaviour - but it is still open 
Here’s a release where it worked as expected:
Here’s one where it did not:
I normally post-edit my imports to take care of things the script misses (and bring them up to code with our style guidelines) but on the latter release I left it as it would appear if I did not manually correct the medleys.
Thank you, I think I have found the problem: The second release was not entered correctly on Discogs, the subtracks were entered as normal tracks with subtrack-style track numbers while the first release uses real subtracks (marked with ↳ symbols).
That was the same issue for me ( https://www.discogs.com/release/16345092 ) So I edited Discogs to fix it on that side.
Weird - even after fixing it still is separate tracks on a test import. Is there a delay between editing Discogs and what the import sees? Or has it cached somewhere from a few days ago?
Track 2.8 works for me if I import it - although the track name “.: Master Of The Universe / Welcome To The Future” looks strange when there is no real section title but the dot for those two subtracks 