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.
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?
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.
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 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
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
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?
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.
