@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.
Strange, for me everything is working just fine as it always did with v2020.9.13.1 using Violentmonkey, although…
I am also using Firefox 84 on Windows 10 (like @Tiske_Tisja)
I am also not logged into a Discogs account (like @HibiscusKazeneko)
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).
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)
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
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).
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
Guess it is a caching issue then. If if works for you then that is good.
Yep, there was a lag of some form. It works perfect now.
I could not work out how to get that done correctly at Discogs. It is not really “encore” as the track before is also part of the encore. “Typical hippies not knowing when to end a track and just confusing our database” didn’t seem to fit.
And Discogs would not let me leave it blank (or put a space there).
I am waiting for some Discogs person to shout and me and then correct it.
Please revert it to avoid EI from some nasty voter there. The tracklist was correct before, see their guidelines about Index tracks vs the standard track/sub-track positions to be used for cases like this: „Separate songs or tunes that are rolled into one track on a CD, LP, etc., should be listed using a point and then a number: 1, 2, 3.1, 3.2, 3.3, 4,… Letters can also be used, with or without a point: A3.a, A3.b or A3a, A3b,…”
I guess the import script might not handle the sub-track positions very well; I don’t remember if I’ve encountered this myself and being on a mobile unable to test right now.
