Not sure, but i think yesterday also was zero on graph. Now there 2724 and 2017. Some bag with graph. Day did not ended, stat for this day not calculated yet, but graph try display this day.
UPD: or not. submit fingerprints for Release “+2” by A Broken Sail - MusicBrainz few minutes ago by Picard, api.acoustid.org return code 200, but fingerprint not in database yet (https://api.acoustid.org/v2/track/list_by_mbid?mbid=815fa12a-1001-430c-8332-d0b0e8eb7dc8)
Logins and fingerprint submissions work fine for me now.
API method submit return OK, but submission freez in pending status. And statistic graph still on zero
Asked on facebook
It’s an ongoing problem we are currently dealing with. The service works, but is unfortunately heavily rate limited.
We had one server going down, taking all the data on the server with it. All of that was replicated, so nothing was lost, but the service is running on tight budget, given that it’s free and one server out will cause things to overload.
That seems slightly confusing as lukz mentions here that it is not a financial issue?
I think that was about money not solving the previous performance issue, because adding another server would not have helped, the application needed (or probably still needs) refactoring.
Tried to today for
and
Nothing up
Don’t think you’ll see anything change until the stat graph perks up: Statistics | AcoustID and\or we hear something from @lukz
Seems that @lukz is doing some work on the AccoustID server code, might be getting a fix in the near future.
13 days without any new additions (or is this just a graphical problem)?
I hope @lukz will let us know with a new blog entry.
UPDATE 24.08.2021:
It seems that AcoustID is back!
I think AcoustID now in read-only mode. API return OK for submissions, so maybe they store in some buffer storage until better times. Maybe not. There is few looks-like-performance-related commits in git log
Do notice the git log dates fit with this thread. I assume the dev is currently hitting the AcoustID server with a tuning fork until he can get it back into singing the correct tune.
I think it is a problem if, when submitting Fingerprints via Picard, Picard reports that the Fingerprint was successfully submitted to AcoustID, when in fact it was not. Having said that, I’m not sure at which end the problem lies.
I think they were received by a queue and they will eventually appear, no?
It’s hard to know. Will they survive two weeks of accumulated queuing?
I don’t know what else Picard could do, though. The acoustid server accepts the submission and returns status 200.
Submissions are processed asynchronously by a background job. However, this normally only takes a few seconds…
API documentation
As far as i understand normal AcoustID API behavior is put submission to database or some buffer and return status 200 (Ok) to client. Seems like this part of AcoustID work well all the time. But another part, that shall somehow process submission and make it usable for users not work at lest last 9 days
That looks promising. Acoustids that I submitted a week ago haven’t yet appeared on the recordings; I imagine there is a very large backlog and it may take some days to catch up.
