Lack of matches due to rate limiting?

[ghbrown]

When running beet import -s on a folder with many songs I often get No matching recordings found for Discogs. I suspect this can happen due to rate limiting (which my verbose logs sometimes show) in addition to an actual lack of a match.

However, when I enter essentially the same query on the Discogs website I get the correct results. To be clear, these queries are so simple I think it is almost impossible that special characters, etc. are causing an a true lack of matches, and what I suspect is happening is the following:

$ beet import -s dir/
*beets makes a lot of API calls for tracks*
*Discogs rate limits me, causing one or more failed requests*
*beets attaches these failed requests to the track and stores this result*
*I get prompted with results for a few successful queries*
*I make it to prompt for failed queries: No matching recordings found*
*rate limit wears off, so I can use manual search mode*

Is this possible? What else could be causing this, are there any simple ways to say for sure?

Also, are there any flags or options I can set to limit how many cached matches I have at once? I would prefer to suffer a bit of latency if it means I don't need to do all these searches manually.

[sampsyo]

Hmm; I suppose it's plausible! It would be really great to confirm in two possible ways (ideally both):

• A verbose log: beet import -vv -s dir/ should reveal more information.
• Trying it again specifically on the songs that failed. If importing the same songs that couldn't be matched before alone suddenly starts working, that would certainly be evidence for the rate-limiting theory!

[sampsyo]

Hmm; good question… a warning surely would be useful! I'm just not 100% sure how to go about detecting which library/version is installed. Maybe the module has a __version__ member we can check?

[ghbrown]

There is a __version__ variable in __init__.py if that would work.

[sampsyo]

That seems like the thing! Any chance you'd feel comfortable putting together a pull request to check that version?

[ghbrown]

I'd be happy to make a PR for this, I'm just not sure which method might be preferable:

• It should be easy enough to check the value of __version__ after import somewhere. However, I'm worried that since both modules are named discogs_client that checking the version this way won't be sufficient to distinguish the two in the case that the PYPI package discogs-client has some version larger than 2.3.10.
• I found importlib.metadata (built in after Python 3.8), which takes a package name and returns a version string. So it would be able to differentiate between python3-discogs-client and discogs-client. Not sure if using this would hurt any efforts to support old versions, etc.
• I could also check for existence of different functions, etc. between the two modules and use that to deduce which package is present.

[sampsyo]

I could be misremembering this, but I believe the reason the new library exists is because discogs-client is officially abandoned—i.e., it will not be getting new versions. So I think we can be confident that there will be never be a discogs-client with a version greater than 2.3.10.