MP3TAG is now randomly throwing out this error. I've done a couple things to attempt to fix it myself -- such as uninstalling and reinstalling, resetting configurations, revoking access, etc. Nothing has worked and now I'm stumped. Google is no help and neither is any of the threads posted in the past about this issue, as none of them have any posted solutions.
Any thoughts?
Including this one?
I actually did not come across that one, I appreciate the reply. I'll get back to you if it fixes it.
This value would be 10'000 seconds = 166 Minutes or nearly 3 hours.
I'm not sure, if you really want to wait that long until a Timeout occurs.
So funnily enough, while it worked for a long while, it is now giving the failed to authenticate error again, lol. (Meant to reply to your post directly.
You get this error using which Musicbrainz-Websource-Script exactly?
Does it occure immediately if you start using Mp3tag on a new day?
Or does it occure after several search attempts?
No only on the discog scripts. Musicbrainz works just fine.
Hello, I have the same problem.
Situation
In December I could use MP3tag (v3.28) searching Discogs. Now it fails with the (partly Dutch) error message:
Failed to authenticate using OAuth (1).
>12002: 12002: Er heeft een time-out van de bewerking plaatsgevonden.
Note, "Er heeft een time-out van de bewerking plaatsgevonden." is Dutch for: "The operation timed out."
What I tried so far
Question
Does anybody have a solution how to fix this?
Thanks in advance!
My system and software versions
Found topics on this forum
I did try the 'solutions' suggested from the following topics without fixing the time-out error.
.Is MP3tag allowed at all to access the internet?
Try Help>Check for new version and see if you get a reply.
Do other web sources work?
Thanks and yes,
MP3tag tells me it is up-to-date (latest version)
I also tried MP3tag on another Windows 11 (not Pro) PC (2). The older MP3tag installation (v3.27) on that machine immediate came with an update request and has the same time-out issue as the Windows 11 Pro PC (1).
After updating it to version 3.28 PC (2) still has the same time-out problem as PC (1).
The same goes for a portable version of MP3tag: it asks for an update and has a time-out in the old (3.27) and the new (3.28) version...
Maybe it is my internet router?
Damn, yes! If I connect to my phone's hotspot (bypassing my normal internet router) Discogs immediately asks for a new permission and works!
It is my FRITZ!box 5530 fiber router! or my internet provider... 
Thanks and sorry for the fuzz, it must be some update in my router or internet provider...
Do you or anyone else know what data traffic might be blocked?
We just had a similar problem here, the cause of which was a fixed MTU setting in the router.
But that can't be the cause for you, as Fritz!boxes don't have such a setting option, as they support MTU clamping by default.
Or do you have another router between your PC and Fritzbox?
Thanks Poster!
I don't use another router and I have no problems connecting and using Musicbrainz.org in my current configuration.
Is this MTU clamping also used to connect to Discog.com? Or any specialized ports?
If I make a VPN-connection (using Windscribe) I can connect to Discog.com without problem. So I think it is my internet-provider.
I would like to know what to ask them. I mean: what port or network traffic is probably blocked?
As a test, I added a screenshot of the NETSH-command suggested in the "Can not reach musicbrainz.org with WSS)" you suggested. Maybe this gives another insight.
It is called MSS Clamping.
It happens all the time because your Fritz!box has this feature by default. That means that normally there should not arise any MTU-size problems. You can not test with ping and the df-flag if lowering the mtu-size anyway shows any success because discogs does not answer to ping commands. So you could only test it with lowering the mtu-size for your actually used net-adapter, but I don't think that this is the reason for your problem. Anyway: Just test it with an MTU-size of 1400.
Open a windows command prompt with administrative rights and enter:
netsh interface ipv4 set subinterface "Ethernet, zwart (HP, Realtek)" mtu=1400 store=persistent
Don't forget to set it back to 1500 later.
Do you have these problems with discogs only with the webscript and Mp3tag or do these timeouts also occur when you access discogs.com with a browser?
I can see, that you have WLAN and Ethernet both connected. How do you access the internet, with WLAN or Etrhernet?
I think that was a wrong assumption on my part regarding the behavior of the ping command. It is true that discogs.com does not respond to ping. However, this apparently only comes into effect when the ping command reaches the address.
In my test, ping -f -l 1470 discogs.com results in the package not getting through because of the defragmentation ban. If I reduce the value to 1460, the command goes through and I get timeouts because only then is discogs.com reached and, as stated, does not respond to pings.
Conclusion: You can definitely carry out tests with the defragmentation flag even though the addressee does not respond to pings.
Thanks and sorry for responding so late.
I tested the MTU-settings and pinging as suggested with command: ping -f -l 1460 discogs.com
Resulting in:
Strange thing is: MP3tag is now working with both mtu-settings.
So I think my provider opened a port again?
Anyway MP3tag is working with Discogs again now. Thanks!
P.S. I never had a problem with the Discogs website in my browsers. Only MP3tag not connecting to it
