PICARD-2584: Load recording if AcoustId metadata is missing

[phw]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences:

Problem

• JIRA ticket (optional): PICARD-2584

AcoustID can sometimes contain no MB metadata for linked recordings. This happens if:

1. recordings have been merged and this merge was not yet handled by the AcoustID server
2. recordings have been deleted and the AcoustID server has not yet cleaned up

AFAIK both should be handled by AcoustID, but currently this does not seem to work correctly (e.g. acoustid/acoustid-server#114). There can always be some time frame where this has not been done as there is some delay in AcoustID database synchronizing., though

In case of 1) this can lead to recording data not being available and files getting matched to standalone recordings instead. It also messes with submission counts.

Examples:

• https://acoustid.org/track/d10da0d8-8b13-4453-9ac5-b179958d01ca

In case of 2) this can lead to files being matched to a standalone-recording that does not load.

Examples:

• https://acoustid.org/track/cb127606-8e3d-4dcf-9902-69c7a9b59bc9
• https://acoustid.org/track/aed07515-2856-4265-afce-247c09e2b12a
• https://acoustid.org/track/47e0f233-9494-4197-b5ab-aa943ab54ee7
• https://acoustid.org/track/85c71305-a4e5-43cf-8a0f-1749cf10edde

Solution

If AcoustID provides no MB metadata but only MB recording ID load the recording data from the MB web service. This is done by the new RecordingResolver in the picard.acoustid package.

If metadata is provided, the recording is used directly. If not a MB web service call to load the recording is initiated.

If the recording no longer exist (404) then the result is ignored. If it exists and was redirected to another recording MBID that is also linked to the same AcoustID, the submission counts get combined.

[phw]

@zas I made a few enhancements, and I think this is now ready for review. With the changes I don't get significantly longer loading times while still eliminating the standalone recording results for my 5k test files.

The changes allowing this are:

• If a recording without metadata is returned from AcoustID it is ignored unless it has more then 25% submission count compared to the recording with highest submission count.
• Loaded recording IDs are cached and only loaded if they are not in cache. This avoids loading the same recording twice. This cache includes redirects.
• A max. of 3 recordings without metadata are resolved for a single AcoustID. That means any AcoustID lookup never can trigger more then 3 additional lookups. The 3 recordings being looked up are always the three with the highest submission count.

[zas]

Very clean patch, good job! LGTM