Yeah, that would be my guess too, specially since yesterday (I think) I noticed a Cloudfare "validation" page a few times when I went into the site through a browser (never happened before, fwiw).
But yeah, trying to access site through a browser first (and maybe navigate it a little) could help, although don't know if CF's whitelisting is client based, or IP based.
Edit: I remember now that CF's whitelist/authorizations are at client/browser level.
Yeah, have the same screen/messages. It seems that for the time being unless there's a way to impersonate another browser (more of this below), we are SOL as AFAIK the challenge is only valid for a single client/browser, instead a single computer/IP.
IDK, maybe there have been a lot of unusal traffic/requests towards MA? I recall that some few weeks ago something similar happened to another site and it lasted for some days until it "got back to normal".
About impersonation:
I know that there's a way to bypass this, but we need to manually use same user agent as authenticated/authorized browser, as well a couple of cookie values for the request. I know for sure that works as in another application, to download stuff from another site, we require to do that every time that we start a new session.
However, in this case, I don't know if this is even possible with MP3Tag... I haven't seen anything like that on application's configuration, and certainly don't know if it's possible to implement on scripts (would need to check, but I don't have my development machine with me at the moment).
Hello, everything worked perfectly with this script for Metallum until I had a few days when he sent me this error message? And i believe that the problem is because Metal Archive site now use Cloudflare security. If any body can help me to fix that please?
Hey there,
Unfortunately, I can't see any "feasible" way (yet) to fix this with what available tools/options we have as this is on site's site rather on script's side. So, until CF and/or MA decide to be less strict, I think that only thing left is to wait (by the way, MA has been using CF since at least 2020, based on some posts that I saw on MA's forum).
Nonetheless, I still will check to see if I can find any lead or idea to have a workaround, but as far as I know the only way that I know (see my previous message) is a little bit convoluted/annoying to even attempt (in this scenario that is) and I don't even know how it could be implemented.
In any case, unless someone else comes with a fix/workaround, I'll update as soon as I can confirm if I could find a workaround or not.
Don't know if you have tried recently, but it seems that Cloudfare issue is no more. I've done some tests and can connect as usual.
Everything works perfectly again....!!!!!! 
Unfortunately not for me. I still get this error ->
Yeah... Probably Cloudfare still "thinks" about your client(s) as a potential threat(s).
In my end, apart Metal-Archives, I had that "show me you're not a a robot" annoyance a lot, but a lot... It was more annoying than anything.
it only worked for 48 hours, the nightmare returned ....... > 403: Forbidden 
Yeah, can confirm...
Don't know what's happening on MA's/CF's side, but it seems that whatever it is, it'll take a while to get it back to normal.
Former Cloudflare employee here.
I can tell you right off the bat that the MA admin has implemented Super/Bot Fight Mode. This was probably preempted by some kind of incident.
S/BFM is a 'product' (inasmuch as it simply populates WAF rules) designed to mitigate automated traffic using Managed Challenges.
This should give you an idea of what MA is looking at on their CF dashboard. They've configured it to be pretty aggressive from what I can tell.
The reason that end users are able to access MA from a browser and not via this script is because they are treated as two different categories of traffic; the latter being "Definitely automated" and blocked with "computationally expensive challenges".
S/BFM is essentially a super watered down version of CF's enterprise grade bot security solution. We used to joke that it was "like taking a blunt instrument to the problem and hoping everything still works". S/BFM offers all of CF's bot detection technology without the tooling to define which bots should be permitted on the granular level.
Basically, as long as MA has this feature toggled on, WS is not going to work.
In a perfect world, MA would push all their HTML to CF's CDN so that CF would eat all the traffic and reduce the strain on MA's origin. Bot traffic would be a null issue in this case.
In the meantime, we can cross our fingers that MA turns S/BFM off so we can use this script again. It's literally just a toggle on the dashboard. I think it's plausible that they would do so since the 'human verification' page degrades the end users' experience.
Woah! Thank you so much for such insightful explanation. I think that most of us, users, aren't even aware of such tools on server's side (using a quite generic name).
Have a question, if you don't mind: is it normal, under this tool's context, that sometimes we're flagged to being blocked, and sometimes not? I ask as a couple of days ago I was able again to use the script with issue for a while (a few albums that I needed to integrate into my library).
Nonetheless, thank you again for your reply, it's amazing!
Kind regards.
P.S.
We used to joke that it was "like taking a blunt instrument to the problem and hoping everything still works"
This sounds exactly as something that is currently happening in my workplace LOL although we described it as "having a flamethrower to light a birthday candle and hoping not burn down the house" haha
hi, i have the same problem since two days, but i don't know how to fix it 
sometimes metal-archives block this, maybe database updates or somethig else.. try a few hours later, and it will work again. i had this often at tuesday and wednsday...
thank you very much for your reply, but the problem has already been solved 
Hi there, good day.
Yeah, in the past few weeks (at least) MA, or rather CF, has been very aggressive when dealing whit new connections, even through regular browser navigation.
I haven't been using MP3Tag that much since last December due to some stuff going on IRL, but I'll take a look to see if anything has changed in the way that application connects to sites (when not using an API - like MA) just to see if anything can be done (I have an idea, but even as a draft it's somewhat convoluted from regular user's standpoint).
Otherwise, I think that were out of luck, and will have to wait until CF get more relaxed.
Thank you ! I'm lost without metal archives.
I look forward to hearing about this situation.
Hi! Is there any chance to include a field which indicates if a song it's marked as a instrumental one?
And 3 issues btw:
Besides these issues, great script, very helpful. Thanks in advance.
