I am unable to submit acoustID for this new release I Added:
Could someone else kindly do it? When I load this into Picard, I do have the following in the error log, but do not have time at the moment to address the. I Ask for help only so it does not get forgotten and left incomplete. Thanks.
E: 04:33:18,820 /usr/lib/picard/picard/webservice/init._handle_reply:387: Network request error for http://api.acoustid.org:80/v2/lookup: Socket operation timed out (QT code 4, HTTP code 0)
I had tried a few times and can confirm I have no issues connecting to internet or MB services, so I posted. But I have also not received a message (from you but automated) indicating it is off topic, so I guess I can just leave it alone. I just thought maybe someone else might have the release and could assist by uploading the ID.
I agree it could be any number of thing, thus I also tried alerting the Picard people in case they should hear of similar issues. I have no clue what is wring with this, but I guess forget it.
AcoustID is not run on any MetaBrainz infrastructure and is not related to MetaBrainz per se, so being able to reach any MetaBrainz servers does not really say anything about being able to reach AcoustID servers.
Re: offtopic: Most of the Picard people that read the Picard category will also read along here; there’s no reason to “crosspost” on the same forum. It just adds clutter and splits the discussion. Which is why I marked your other post as offtopic and hid it. Note that I didn’t mark this post as offtopic, which means the topic itself is not offtopic—only the double/cross posting.
Yes, I can access the resources you listed, although I had originally only tried the resource specifically listed in the errors. I understand that is not hosted on metabrainz servers. But I also know that the Picard programming makes the call(s) to the servers it is on. I have personally seen times where an issue in the “calling code” is in some way invalid or malformed, which can cause the server to timeout on the request. Given this, I would logically assume this information would be of interest to Picard project programmers, as there was an issue while using the product. It may not be an immediate attention sort of thing, but it is something that is often logged for error analysis and possible correlation with other error reports.
For example, I am currently working on an issue where “503 server unavailable” is received by some but not all. Simple logic will tell you to try later, the server is simply not available. But looking at this, that is not the case. The code making the call is getting changed for some users, as I can duplicate the issue by manually altering the call. Maybe a browser, extension, etc issue, unsure, but it is surely something I want to know.
I can try again later when I am on a computer with Picard, but I also do not like leaving my edits incomplete, at least to the extent of my MB knowledge and information available. There are also limited ways to submit the acoustic ID which makes issues like this a show stopper as it relates to that function.
Got a problem since maybe one day Picard doesn’t let me check any files via AcoustID. I get a quick “Network error” and the log says something like this:
webservice._handle_reply:387: Network request error for http://api.acoustid.org:80/v2/lookup: Error transferring http://api.acoustid.org:80/v2/lookup - server replied: Service Unavailable (QT code 403, HTTP code 503)
D: 21:39:40,069 webservice._handle_reply:398: Retrying http://api.acoustid.org:80/v2/lookup (#1)
D: 21:39:40,074 webservice.ratecontrol._slow_down:191: ('api.acoustid.org', 80): slowdown; delay: 16000ms -> 32000ms; ssthresh: 0; cws: 1.000
D: 21:39:40,078 webservice.ratecontrol.get_delay_to_next_request:119: ('api.acoustid.org', 80): Last request was 76 ms ago, waiting 31924 ms before starting another one
D: 21:39:40,082 webservice.ratecontrol.get_delay_to_next_request:119: ('api.acoustid.org', 80): Last request was 80 ms ago, waiting 31920 ms before starting another one
Fingerprints are not sent to or or stored on MusicBrainz servers, but only on AcoustID. The MusicBrainz pages have code that calls to AcoustID to get the AcoustID ids, but if AcoustID is down, then that code won’t be able to get those ids.
AcoustID began encountering issues about 00:00 UTC and stopped working for me completely about 00:30 UTC. I was using it at the time and began monitoring the dashboard here: Grafana
AcoustID is not maintained by MusicBrainz, but by an individual (lukz) who will likely remediate the issue or provide an update when he gets to it.
The website is up sometimes but the API (which I assume is also used for submissions) has been dodgy all day. It works sometimes, then breaks again. I chose the worst possible day to test my code for the Fingerprints tab!
