# \[WS\] Metal Archives

**URL:** https://community.mp3tag.de/t/ws-metal-archives/5923
**Category:** Web Sources Scripts
**Created:** [December 20, 2007, 2:52pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923 "2007-12-20T14:52:32Z")
**Posts on this page:** 20
**Page:** 5

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 13, 2024, 12:50pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/83 "2024-04-13T12:50:28Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![slayerist](https://community.mp3tag.de/user_avatar/community.mp3tag.de/slayerist/32/4940_2.png) [@slayerist](https://community.mp3tag.de/u/slayerist)
#### Post date: [April 13, 2024, 3:14pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/84 "2024-04-13T15:14:13Z")

</div>

![brave_screenshot_www.metal-archives.com](https://community.mp3tag.de/uploads/default/original/3X/2/9/299b3b0ee39b82e3256695adda5021dd3b83368e.png)  
 ![uD9COFcc4K](https://community.mp3tag.de/uploads/default/original/3X/2/1/21791b209a140748d06adc815f7da5a6db1c444a.png)

Same here!

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 13, 2024, 7:28pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/85 "2024-04-13T19:28:07Z")

</div>

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).

---

<div class="post-metadata">

### Author: ![5tr1x](https://community.mp3tag.de/user_avatar/community.mp3tag.de/5tr1x/32/16700_2.png) [@5tr1x](https://community.mp3tag.de/u/5tr1x)
#### Post date: [April 13, 2024, 8:55pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/86 "2024-04-13T20:55:43Z")

</div>

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?  
 ![2024-04-13_061910](https://community.mp3tag.de/uploads/default/original/3X/3/f/3fa716fafbb7b9b01c944c2c3273329870ab99e3.png)

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 14, 2024, 7:17pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/87 "2024-04-14T19:17:17Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 24, 2024, 5:00pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/88 "2024-04-24T17:00:40Z")

</div>

@5tr1x

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.

---

<div class="post-metadata">

### Author: ![5tr1x](https://community.mp3tag.de/user_avatar/community.mp3tag.de/5tr1x/32/16700_2.png) [@5tr1x](https://community.mp3tag.de/u/5tr1x)
#### Post date: [April 24, 2024, 10:44pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/89 "2024-04-24T22:44:48Z")

</div>

Everything works perfectly again....!!!!!! 🤘 💪

---

<div class="post-metadata">

### Author: ![sargeist666](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/d6d6ee/32.png) [@sargeist666](https://community.mp3tag.de/u/sargeist666)
#### Post date: [April 26, 2024, 7:22pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/90 "2024-04-26T19:22:58Z")

</div>

Unfortunately not for me. I still get this error -\>

![image](https://community.mp3tag.de/uploads/default/original/3X/6/0/60bf504557a62da985f66d5b3d9ad9ba9abbe4b0.png)

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 26, 2024, 7:52pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/91 "2024-04-26T19:52:04Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![5tr1x](https://community.mp3tag.de/user_avatar/community.mp3tag.de/5tr1x/32/16700_2.png) [@5tr1x](https://community.mp3tag.de/u/5tr1x)
#### Post date: [April 28, 2024, 1:12am UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/92 "2024-04-28T01:12:58Z")

</div>

it only worked for 48 hours, the nightmare returned ....... \> 403: Forbidden 🥵 😟

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [April 28, 2024, 1:26am UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/93 "2024-04-28T01:26:46Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Toutious\_Sextius](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/ec9cab/32.png) [@Toutious\_Sextius](https://community.mp3tag.de/u/Toutious_Sextius)
#### Post date: [May 20, 2024, 12:37am UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/94 "2024-05-20T00:37:14Z")

</div>

Former Cloudflare employee here.

I can tell you right off the bat that the MA admin has implemented [Super/Bot Fight Mode](https://developers.cloudflare.com/bots/). 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](https://developers.cloudflare.com/waf/reference/cloudflare-challenges/).

 ![Bot-Report-current](https://community.mp3tag.de/uploads/default/original/3X/5/1/5185849164d2f422386d6b45c0631c6769117dd1.png)

 ![configure-biz-current](https://community.mp3tag.de/uploads/default/original/3X/b/6/b6ef68d7b1e77d0f68c33d2a35ae2af62b73cd89.png)

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.

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [May 20, 2024, 1:47am UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/95 "2024-05-20T01:47:56Z")

</div>

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

---

<div class="post-metadata">

### Author: ![MONIKADAVRE](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/46a35a/32.png) [@MONIKADAVRE](https://community.mp3tag.de/u/MONIKADAVRE)
#### Post date: [September 18, 2024, 12:02pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/96 "2024-09-18T12:02:12Z")

</div>

hi, i have the same problem since two days, but i don't know how to fix it 😅  
 ![Capture d'écran 2024-09-18 serveur metal archives](https://community.mp3tag.de/uploads/default/original/3X/0/2/029549a4ba66254ed5b517a1f1f42a26e7d3962b.png)

---

<div class="post-metadata">

### Author: ![bigbear22941](https://community.mp3tag.de/user_avatar/community.mp3tag.de/bigbear22941/32/8134_2.png) [@bigbear22941](https://community.mp3tag.de/u/bigbear22941)
#### Post date: [September 28, 2024, 7:02am UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/97 "2024-09-28T07:02:53Z")

</div>

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...

---

<div class="post-metadata">

### Author: ![MONIKADAVRE](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/46a35a/32.png) [@MONIKADAVRE](https://community.mp3tag.de/u/MONIKADAVRE)
#### Post date: [September 30, 2024, 9:02pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/98 "2024-09-30T21:02:09Z")

</div>

thank you very much for your reply, but the problem has already been solved 😉

---

<div class="post-metadata">

### Author: ![MONIKADAVRE](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/46a35a/32.png) [@MONIKADAVRE](https://community.mp3tag.de/u/MONIKADAVRE)
#### Post date: [March 27, 2025, 2:10pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/100 "2025-03-27T14:10:56Z")

</div>

I've had this annoying problem for a few days now, I wouldn't mind some help.

 ![029549a4ba66254ed5b517a1f1f42a26e7d3962b](https://community.mp3tag.de/uploads/default/original/3X/f/f/ffb3c82cc484b0aae9df8f42b38033e684dc82bf.png)

---

<div class="post-metadata">

### Author: ![anton](https://community.mp3tag.de/user_avatar/community.mp3tag.de/anton/32/16235_2.png) [@anton](https://community.mp3tag.de/u/anton)
#### Post date: [March 27, 2025, 2:59pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/101 "2025-03-27T14:59:46Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![MONIKADAVRE](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/46a35a/32.png) [@MONIKADAVRE](https://community.mp3tag.de/u/MONIKADAVRE)
#### Post date: [March 28, 2025, 12:28pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/102 "2025-03-28T12:28:34Z")

</div>

Thank you ! I'm lost without metal archives.  
I look forward to hearing about this situation.

---

<div class="post-metadata">

### Author: ![Jaeger1349](https://community.mp3tag.de/user_avatar/community.mp3tag.de/jaeger1349/32/19547_2.png) [@Jaeger1349](https://community.mp3tag.de/u/Jaeger1349)
#### Post date: [April 1, 2025, 6:28pm UTC](https://community.mp3tag.de/t/ws-metal-archives/5923/103 "2025-04-01T18:28:02Z")

</div>

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:

- I've checking and comparing the source code of the two latest releases, and in the section #date, a working regexp was changed, the one who retrieve as "yyyy-mm-01" a release album date without the day. v20240218 was ok.
- When a release album date only has the year, the regexp doesn't work as expected (returning "yyyy" instead of "yyyy-01-01"). My knowledge on regexp is limited, so I can't address the exact problem just with looking at it.
- Checking the source code, I found a "METAL ARCHIVES BONUS" line/function, it works? I ask this because if it is for retrieve if a song is a Bonus Track as I think, it doesn't retrieve anything.

Besides these issues, great script, very helpful. Thanks in advance.

[Previous page](https://community.mp3tag.de/t/ws-metal-archives/5923.md?page=4)

[Next page](https://community.mp3tag.de/t/ws-metal-archives/5923.md?page=6)
