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

AcoustID
#1

Hello,

I loaded 3 releases in Picard:



For teh last one I had to manually attached each track to the release

Then for all releases I clicked Generate AcoustID fingerprints within picard
When done I clicked “Submit AcoustIDs”

Then no fingerpritns was appearing for Best of 2008

So I try to load again but only one track and submit AcoustIDs and then the fingerprint directly appeared in MBz

Are we forced to send release by release?

Are there technical problems at AcoustID?
#2

No, you can send multiple releases in one go. But it might take the AcoustID server a moment to process everything. How long after submission did you check this? Submitted fingerprints go into a processing queue and that needs to analyze each fingerprint and match it against existing AcoustIDs (or create a new one). Depending on the AcoustID server’s load this means the linked AcoustIDs can show up slightly delayed.

1 Like
#3

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:

#4

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

ex: https://acoustid.org/track/bc4ac345-10ef-4b6d-9c36-47a7f9f99cff
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?

Thanks

#5

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

#6

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

1 Like
#7

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 https://acoustid.org/stats

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

UPDATE: This is one of the pending submissions: https://api.acoustid.org/v2/submission_status?client=TP5_yyfxUAs&id=123456789&id=575918262

2 Likes
#8

Hello,

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: (‘musicbrainz.org’, 443): Last request was 85131 ms ago, starting another one
D: 07:31:42,385 webservice\ratecontrol.increment_requests:138: (‘musicbrainz.org’, 443): Incrementing requests to: 1
D: 07:31:43,347 webservice\ratecontrol.decrement_requests:146: (‘musicbrainz.org’, 443): Decrementing requests to: 0
D: 07:31:43,347 webservice_init_._handle_reply:484: Received reply for https://musicbrainz.org:443/ws/2/release?release-group=87ddc705-6dab-4b18-907d-5dbb117c2a05&limit=100&inc=media+labels: HTTP 200 (OK)
D: 07:31:43,350 webservice\ratecontrol._out_of_backoff:229: (‘musicbrainz.org’, 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 https://musicbrainz.org/release/a3d20e2b-3b71-4872-b1bc-261c3154fa2d?tport=8000
The input worked as number of sources changed for the recordings but strangely no metadata sent, ex on 1st track:
https://acoustid.org/track/bc4ac345-10ef-4b6d-9c36-47a7f9f99cff

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?

#9

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

2 Likes
#10

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?

#11

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

1 Like
Problems displaying acoustids
#12

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

#13

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

#14

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.

2 Likes
#15

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

1 Like
#16

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

#17

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

2021-02-11 10_05_00-Statistics _ AcoustID
2021-02-11 10_05_00-Statistics _ AcoustID1363×421 41 KB

#18

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
#19

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.

3 Likes
Problems submitting AcoustID
#20

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!
https://musicbrainz.org/recording/05600fd1-a8ec-44f0-9514-7e33408df285

1 Like