Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
fetchart: Restore iTunes Store source #2718
This is a tentative at addressing #2551 . For the moment this is very much a work in progress, but I would like to discuss some points.
For the moment I took python-itunes from @ocelma, stripped it of some unnecessary stuff and fixed some stuff to make python3 compatible.
Open questions are:
Cool! I'm very much in favor of adopting the code ourselves to help get this functionality back into shape. Let's do it!
Trimming the necessary code down to its essence does make it possible to keep things simple. If we can get @ocelma's consent to relicense the code under MIT, let's provide proper attribution and start simplifying down from there. After a quick look, it seems like it shouldn't be too hard to pull out the pieces we need.
On the other hand, if we don't hear back from @ocelma, then publishing a separate module to PyPI would be an acceptable fallback that would keep the GPL implications contained.
I am currently writing the changelog and doc before merging.
Looks perfect! Thanks for all your effort on this.
Your earlier question about criteria for inclusion as a default source is a good one. Fast-ish is a good idea, but it seems like this source will be pretty fast too. The exact definition of “fast enough” is open to interpretation.
Aug 15, 2018
0 of 4 checks passed
I would like to add a note about iTunes Store rate limiting. The doc says it is limited to about 20calls per minute. Trying by hand it is definitely higher, but I was still able to get rate-limited.
For that reason this provider might start to error out and not provide candidate during a batch import, for which it might not be the ideal provider.
Is this worth mentioning somewhere? What makes me not like this is that the failure is silent unless beets runs in verbose mode, so there could be some extreme case where no cover/a non-perfect is found although one is available on the itunes store and the user is not aware of that.
A possibility would be to check if the http error can be detected for rate-limiting and then issue a warning of some kind.
Hmm; interesting point. Another alternative would be voluntarily rate limit ourselves—that is, keep track of how much we’re requesting and gradually slow things down. But 3 seconds per call (on average) is pretty slow.
It’s probably worth at least mentioning in the docs. A visible warning may be fine but could get noisy and annoying in the context of a full, interactive import.
Correction: I actually made a typo when mashing my keyboard to test the rate limiting.
I can't seem to reach the limit even when letting it loop for 10 minutes straight.
You could try it out on your side, but I think for the moment we can leave it at that.