AcoustIDs not sent despite Picard says Sucessful when doing on more than one release

Hours, as I m still not able to see whereas less than a minute when I ve done it for first track of the release only.
Then tried again this morning and still didnt work so more than a day.

What I can notice is in Picard (bottom right panel) no AcoustID appears on each track for this release compare to the 2 other ones.

Based on that I put all files to the left frame of Picard, run Scan, then drag them to the proper release on right side. Now there are some progress as the AcoustID finally appears in the bottom right frame of Picard but still nothing in MBz.

Then tried again upload per track only and it directly worked.

So I m a bit lost :slight_smile:

HEllo, tried some more tests with other releases and seems I dont upload anything except if doing by track.
And even so no metadata are sent

Tried to send by release regenerating fingerprints, nothing sent as figures dont change (was 3)
Tried to send by loading only this track and regenerating fingerprint, figure changed to 4 but still no metadata sent.

Does the problem seem to be on my side or the server one?


I’m also having problems trying to get submitted fingerprints to show up. I haven’t tried sending only one track.

Can you enable debug logging in Help > View Error/Debug log, do the submission and give the debug output here?

1 Like

I ǵave this a test here with roughly 50 fingerprints. I can kind of reproduce this issue, but it is on AcoustID side. I moved this topic into the AcoustID category.

What I noticed:

  • In general submission currently is pretty slow, twice I even ran into Picard’s network timeout (30 seconds) when trying to submit. The rest was reported successfully, with AcoustID returning a pending submission ID for each fingerprint.
  • Most of my submissions never increased the submission count. Even submitting the same fingerprint at least 10 times only increased the counter for one case twice, one of which was for a single submission. But single submission does not seem to be a guarantee that it shows up.
  • The submitted fingerprints today are higher than the last days, see

Looks like some load issue on the server. @lukz Can you give any info?

UPDATE: This is one of the pending submissions:



To add the retrieving of fingerprints was also really slow past days: Like 5 mins to scan a 50 tracks releases in picard. On web part with in line plugin sometimes fingerpritns were not even retrieved.

Then good news the try from this morning worked,!All fingerprints are linked now and here is the msg that appeared in Picard after 1 min:

D: 07:31:42,362 webservice\ratecontrol.get_delay_to_next_request:118: (‘’, 443): Last request was 85131 ms ago, starting another one
D: 07:31:42,385 webservice\ratecontrol.increment_requests:138: (‘’, 443): Incrementing requests to: 1
D: 07:31:43,347 webservice\ratecontrol.decrement_requests:146: (‘’, 443): Decrementing requests to: 0
D: 07:31:43,347 webservice_init_._handle_reply:484: Received reply for HTTP 200 (OK)
D: 07:31:43,350 webservice\ratecontrol._out_of_backoff:229: (‘’, 443): oobackoff; delay: 1000ms -> 1000ms; slow start; window size 9.000 -> 10.000

How to ensure it will continue to work prioperly in the future? If I remeber well kind of same issues happend 1,5 month ago where it was impossible to connect to the server in http.
Could it help to clean db by removing the history of “Unlink” and wrong tag that can be automatically removed (many fingerpritns are linked to recordings with only 1 source, no metadata and huge duration difference)

edit: Also tried to contribute on this release
The input worked as number of sources changed for the recordings but strangely no metadata sent, ex on 1st track:

edit 2:
Tested on around 200 releases at the same time and it seems to have worked as last recording got one more source but as before no metadata sent
Does it link as I just use “Generate Fingerprints” function and not a full scan?

Actually Picard doesn’t send additional metadata as it sends a recording ID which already identifies the details of the recording.

I don’t know if the AcoustID server would benefit from additional metadata. But as @lukz implemented both the entire AcoustId system and the submission from Picard I assume probably not. It would increase submission size though and mean we need to do more requests to submit the fingerprints.

As I understand it the metadata is useful when submitting fingerprints without MBIDs


I reported those as I thought it was normal behavior from Picard to send those metadata to server. Then totally agree not to send them.

Regarding other problem (Acoudt ID not sent), what was the issue? Will it happen again in future? Will be the data cleaned up one day?

I don’t know, I also don’t have any insights into the AcoustId server. Maybe Lukáš will give some insights.

1 Like

IS there a way to contact him?

Tried again this morning different tests and some time working directly, sometime after few time and sometime never

Sorry to come back on topic but is there a way to have a clean up of all the obvious wrong linked tracks?

i am having a similar problem. it should be thousands of new ID’s i submitted, but they never got recieved and displayed on MB.


Same issues here. Also getting a lot of 504’s when unlinking.

1 Like

I’ve had that for a few days now. Just can’t unlink at all at the moment.

AcoustID seems to have a problem actually, there or no new additions (since) yesterday?

Still impossible to unlink or add an ID.
Based on last months it seems the site is only working properly few days every two weeks
Rest of time there is latency in adding data or retrieving and now it became unsable

1 Like

This is a worrying state. I’ve also noticed it as I was in the middle of a big clean up. I have Userscripts that put AcoustIDs onto release pages and it is making everything very slow.

I wondering if that server is suffering from DDoS? Or just plain overloading of the resources available? The silence is a little worrying.


I did a merge this week and I am I have now lost a heap of acoustID fingerprints. Would this make sense with this major outage \ hiccup at the AcoustID server? Will they come back?

I know there were many AcoustIDs on this before the merges, but not only one shows up!

1 Like

This is quite worrying me now. I have a number of recording merges lined up. I hope there is a way of rebuilding that data once the AcoustID server comes back on line. I am fairly sure I am seeing a lot of missing fingerprints on other tracks.

Even just on a human level - is the guy running the server okay? Has anyone heard from him to check he is healthy and happy? Loosing a resource like AcoustID would be inconvenient, but I hope nothing has happened to @lukz as this is now a long time with a lot of silence.

I have never talked to the man, but wish him all the best with whatever he is going through.


Some news on this thread