AcoustID issue

That’s a bit different then the case here, in the case of this topic there are actually zero results for the fingerprint lookup.

But you are right, Picard currently sets the acoustid_id tag once it has found a matching recording. We probably really should always set this tag, even if there is no recording matching. I did just that in https://tickets.metabrainz.org/browse/PICARD-2273

Of course this does not make a difference for the case of no AcoustIDs. We can’t set this tag if there is no AcoustID at all :wink:

I have to correct myself here. For AcoustID lookup this threshold is not used, so it will always match against a found recording. It will still try to use the best matching one, were it also considers the count of submissions.

4 Likes

Great! Maybe do it when you generate an acoustid aswell cause that’s another thing that gives very little feedback to the user in my experience.

Picard doesn’t “generate AcoustIDs”, the AcoustID server does.

1 Like

I am sure I did this quite a number of times, but why not try it again? The track being in the right pane with a red fingerprint, I just clicked on Submit AcoustIDs the red fingerprint turned grey and got a message in the status line telling me the AcoustIDs were correctly submitted. Here is the corresponding log:

Picard log
D: 17:16:52,013 config.event:167: Config file update requested on thread 19484

D: 17:16:57,075 acoustid\manager.submit:113: AcoustID: submitting total of 1 fingerprints...

D: 17:16:57,076 acoustid\manager._batch_submit:160: AcoustID: submitting batch of 1 fingerprints (0 remaining)...

D: 17:16:57,104 webservice\__init__.post:533: POST-DATA 'user=fb4VTyCv&fingerprint.0=AQADtJGYJImmLBLMxEf4C3fBvvjw40yGWinRHc87XMpBMrSO-vCjF3015AmhcUJ67aioH_3gvsdDOFpuUCquSjHaISTDQg-PHx6jBxqjiNDd4z7CqCF6HmV2wdsXIZcGuTnC48cThRSe6ai4I_2hPciZCfcH_kH5IEwV6GTxIPpRwWKN6N1xDZaJS4Lm5AHNCz3Ww4c-wmGOG_Hgo8eXGLeLr0cjH3143BLqHD1zxJcjtNmhxcElC2E5uA6Xwc5RH0ezxEaoGt-gtCKF8EePX8OzLFJCXPbwcGisHf2P3cYznLhooz_8wA6PmzkunMfnI58G8cePvLvR40qPbod5lBfOI_eQPBFOH82J8gr-HDk0jUuFaPrhXMdk9FKChjly4UfXQOWFpw7MKEcPfVmOMBUvfNnhZzHK4z8u8uiTBZt4VI9QL0Dy5Qjz44mOb_pwNP_RZ86GF_-R_-gzaDl07cb0DA2PJy_-H10Jf4WO_YR_5Mfx4jvip9CRh7CL6_jxJ4fzW7BG4dWCWseJkq3xB66PG8-aoLqK8BXcC9qPE6OKDmmPuz1ew_mDLsxRmWjGEL_xoySPP_jxeCecMjGe4_DhN0eP_NAVBVOiF92LSlfhSvjxdYX2QBsc5niO-ILl6Akc9MejI3t6fByhG_2iosmNa9kkPEkC8Dl6Q0t_HDmxi6nRh0X6Q8PTpQj7B56uIHSEQ1unwmNQrUedH64IHb6Lfsdz6MmRjx7OoNfhyImFbjpeGaV0pNyD9_iDTU-IXhlUSWKDLwmD-DuaH32Ciygj_fCJ5iV4cXhy5NORPHiSnbjW44zQPDz640_BN8P9Ix8PLVX2orIUEtN6hIl6PDSaJsxRi0cfpE8qaLKEcEkER0su1LfwH-EPMUck5Urx_JjIHO7yEU-WvEIuqOkRSj2e4zrRH02dDo9e_OEQKk8hzkc7Dle04LvQvxCPMogTLXhSVB_R5Hg_XEelJ9txH8-PerOOnwiT5EJ1Hc-OxtCoReERHj-cvLieTcQ74WimaME3H2i-ozrxpdxQK0F66AnClZRxZYluXGksXOh3osmjHO9xyTmukLhyNHxQksejGP8RRi80XUduvIvgJQ_eHBepGc2PKpOEN0fFI8yjvFBdIv_whOHxiJyEki9sbcd5D28uVMdx_Qjj5KhJ6FFShLkoVHfxHM1YtNGHK8c__Ah_-HmIOtpRi4Tf4lfxCDoiiZSFa41x36iWozlz4cwxnTlc5diPMFWWIzmNF8-7oIm8DhNz1ErxNMdn4VTxIp2241M-ONllfIS-HPkeVMczVbiy3Kh8NCOPM3TxvHiSoYl49JbwZnFwyUcfbCqDZM4Rihf842Xh7EV95PmIqnEDv7iC9PjhX6i4S_jCIA91nKhESoKidAv06cIVLg7CFS6PX6iJnETy4lGe4DzR3WjiLMePc8fO40qUKmB4PMeYZ0hjFsl83AkVPFKUUPgX_KgcJEviB7l-PPExEQyZSMadHLuOZnKGUEyOxD7-DD3DCE2kJDuuvLiMR4d7vKHwqccRJpJYIrkuvMczpFcK9UU4RUWlHfuFO4ado0K460iWPHhEBudFvELjZkXlHJce9EVz8DmackEfYV6E7hXC_IEmdUfzHLmOo_lQ7_iLZ_nx65h-o7GkCrHWd5AvpNnBf8LJnHjQ5GCs482NtxmNUMezJDpS7jjpI_0hVzKcD19-pE6Ogt8R6kioob-EZ-EW_MGXEw65I8-PD4oPL7uQJ9llvMlxCU6aD2c3PDauo5eQLB9yPMaTnHgUXTgch8Dp4spSoY_QtMODpKYRKt9xTvDxGWdhJj5KWcd1PD-auBxCR8V5Qjv8hajwhEum40mPSxdC9mi-4xEfXBKDMzMa6iil48aP5kcyxckRv8YbNJOONtHx4N3moRea0EecRdyg60T4JEeDi8GjiMa9odSF5hS-B--Lp8JZfJpRH2Eu6EWeCD_RJC9FlLfwhUIzxagX_MELnziji_gkFuEhfgiXZ8fHObhy3MezHF7SWMSTssEbDT-8DJcy4yYu-JmO-8H-IXmYXEOYiugvXMsToUl7tHHwHT984e6DB5Hyw4e2JLiS5PiRN0eY80EXOXiSHof5Q3Fz4agLXzq0yEuFPApV4ccpw0-K400U4_LRhAmf4OFShDl0hJaUBkzSJSIePXiW40GY0M6hPSeyOfjhKEp24mSO5gpKJsKO9keYE8l1XNLhZxyOF82DUj7xJckT_JOOZkeLJ8xy4YnkoKJ0NM8VJGe3Is-iGA9x1MuDZmwT5EueQtXyC3HgxcEpRbiOH-l7qEIYoeaEkcnQG81FcF98XMedCtWSBx4Z-Mf2HKGha0EuG5caNLeD8rgkB2_CokOYKGuR_E6wJ7PwH3AcnDqeHqeQT0oFvYeuQz_68GhUvD1O4zoa6NKRD35qVJYXXJvx9DiPZHmR5QrOvZgyqUcZ6SyuUsGPvkITKjvOfAt-5IT4ZESu42lwlsITXejVwz-qTFmOXz3-EN_RZkHjLMflbHiD5kSVZh2SfgjzCGWizMKVGC-OHk3xLEwmVPqFSOF4QWeOMEfYF20EZWIzlPKhB_2DMLuE_3iGZkuGWscfXEj4D7FTTXh64T_awFMq9MyR47GGbx-aMHOLrhdyojk6l4hJVbgHxRJNhM-wJUc1zihl9The4g6eH_uDUE-QTLkmbONhXsH_oE6yHD_6C80RS6dwCRWVvPDdQTuDUM7RJErx5cG3ENfhf8V1F_cBxYARnCGgiCAGAECEIAoJAgABwAhKhBEACCGEYQgKIghwxipEhHGICgkEQsBowgmj2AhkgBIAKQGMQQozJAgCghAmhCACXESMNABgYgQgSkghhCHASecMIEABJwXwhAABIAOGKYYEAIQAYRgAUCCDjDDEEKQBQMISIQhCFBigHDOAAEHAgAoYYBRClhMCHCEAAAMAdcoBIRA0hEEglECIGUuEgcQB5AijQFhFmRCOCICRURZYYgxABkhCBCFMCaUEEUQAoBhRQCoCjCOGOEEAEIYQYIAFQAGsEBFAIakQQEAAogEDhCFGDBBACEQAIYYAKAgiABAAkEDAGUMEEgA5AQiRBBFFFDKOMGGAQEYZAByAghkklCQECGgQEQAI6oAgiAjABALEIAsAAwgYASQhCiGBFEEAOAaAAQgAARBFhhiEBFCGMIuYEQoJoYBgCAhBACFECESwQhAIiJRjzAChoHBKSYQAE8QABIRgBFkFEKEOOIAINAABQhQHBghAFCAGCOuYQogQZAgjhhCEmCBCAeOMUAILIIURDjDAgQBOICQZocIQywAxjBiDiGGAUGGAIQgg6wgkhBiBFFAEQAYMAQwhQQAQRBEhDGICAIGQMIQwYYACgoFjAAKcMIQIIYwKIxSrCDAAKHBEGE4AIUgQAYQBRCnCgAEEIWodUkRYoyjBAgmDAFAKOEIQAMQgpIADwjBjAQDCeiEAQUgwAQB1xHKAgFKAECMIEIwRRQFgRlgCmQIKAMQYAMIEIYhEhgkiABFIOIKoAEZQQgBwEGjBgAGgCQEQAQIChAwgQFAGiBGCKIKYEgYBIBBizAhqhAMSAUAIMoIIIygBCkEohAKQGEWEREQJAAFhQBCEBSOCIKWAFIAQBQASBhhBhEGGQOAQYfIAIQAChAAklAOGAQGBJAAYQpQAniJgqFGaAqYQM0IBAgwiQgDECeBAECQIQQgSARAADg&duration.0=505&mbid.0=b3594dcb-cdd9-4015-bea2-f08c46d18a64&client=v8pQ6oyB&clientversion=2.6.3.final0&format=json'

D: 17:16:57,110 webservice\ratecontrol.get_delay_to_next_request:118: ('api.acoustid.org', 443): Last request was 34567060 ms ago, starting another one

D: 17:16:57,111 webservice\ratecontrol.increment_requests:138: ('api.acoustid.org', 443): Incrementing requests to: 1

D: 17:16:57,814 webservice\ratecontrol.decrement_requests:146: ('api.acoustid.org', 443): Decrementing requests to: 0

D: 17:16:57,816 webservice\__init__._handle_reply:486: Received reply for https://api.acoustid.org:443/v2/submit: HTTP 200 (OK)

D: 17:16:57,820 webservice\__init__._handle_reply:495: Response received: {'status': 'ok', 'submissions': [{'id': 602773672, 'index': '0', 'status': 'pending'}]}

D: 17:16:57,822 acoustid\manager._batch_submit_finished:197: AcoustID: 1 fingerprints successfully submitted

D: 17:16:57,829 file.update:665: Updating file <FLACFile '2-03. Dance on a Volcano.flac'>

D: 17:16:57,843 acoustid\manager._batch_submit:140: AcoustID submission finished successfully

D: 17:16:57,843 webservice\ratecontrol._out_of_backoff:229: ('api.acoustid.org', 443): oobackoff; delay: 333ms -> 333ms; slow start; window size 3.000 -> 4.000

When I select the file in Picard, Picard still does not display an AcoustID line, so I guess the AcoustID is still not in the flac file. From your later comment, I understand that this is just what would be expected if there is a server issue. What is strange is that, as I stated before, I handled thousands of flac files and ony a few of them got this problem. So if this a server issue, it is one that affects only some specific files…

I’ll check again in a few days.

I just checked, that submission is still pending. I also tried submitting the fingerprint from the logs myself, but that just led to another pending request. So either there is still some general issue with processing the submissions or something specific to this fingerprint causes issues. I opened an issue for AcoustID:

2 Likes

Thank you. I subscribed to the issue. When / if is resolved, I’ll check my other recalcitrant flac files.

BTW, shouldn’t Picard say something in this situation. Even if this specifc issue is fixed, some kind of similar problem will probably happen again. I understand that Picard does not maintain a database so that if I drag again the file into Picard, it can’t remember it has already tried and failed. But if submission fails, Picard could for example use a different color (yellow?) to show something went wrong.

But maybe this isn’t so important, maybe what matters is that most tracks work?

But picard has a thing that says “generate accoustid fingerprint” if you right click files, this thing should have could give some feedback to the user is what I’m saying. (like adding any tag that gets generated by the server)

Yes. But in my scenario, it seems that Picard succeeded in generating the AcoustID. The problem was later, when Submitting AcoustIDs. And then, because the submit failed, Picard did not write the AcoustID in the file. Which could be a good idea: at least now, I can scan all my files and see which ones don’t have an AcoustID. While if Picard had written the AcoustID in the file even when submission errors occurred, finding which files failed would have been much more difficult.

Actually, IIUC, the AcoustID procedure is different from other tags: the AcoustID is generated by your machine and later sent to the servers.

An AcoustID is a grouping of fingerprints. Picard generates the fingerprint, not the AcoustID. As already correctly stated, https://acoustid.org/ is responsible for assigning the AcoustID that has collected your fingerprint.

2 Likes

No, the AcoustID is NOT generated by your machine nor by Picard. The AcoustID is generated by the AcoustID.org server. You calculate a fingerprint locally (using fpcalc from AcoustID.org) and Picard then send this Fingerprint to the AcoustID.org-server. In best case, you get back an AcoustID.

For details, please see
https://picard-docs.musicbrainz.org/en/tutorials/acoustid.html

2 Likes

Ah OK. Obviously I mixed fingerprints and AcoustIDs. Sorry.

In this case submission didn’t actually fail. The AcoustID server received the fingerprint, and it went into the import queue, where it usually gets processed shortly after. The issue is now that this particular submission gets not processed. What Picard could do is remember the submission, then we could e.g.check the submission status again later.

1 Like