[monkeyman]

As I said somewhere below that, I found a way to add a second sleep time between requests to your script... but fanart.tv still banned me every few requests. I had to cancel the script and restart it, so I could download artwork again.

You're probably right. It has no much sense to implement site by site rules inside the script. May be you could implement some config options so users can "adapt" script behaviour to each site limitation. "cadence" and "reconnect" options maybe? I don't know. You're the master here.

Thanks a lot for your support.

I haven't had time to look at this yet, and assuming the fanart.tv restriction is only temporary I may never get around to it (what they have done is going to screw up Kodi as well, so it's not really a practical solution for the majority of their users such as Kodi).

It's interesting that adding time.sleep(1.0) to force 1 request per second wasn't successful, although I have an idea why that could be. Can you re-try your modified script with the option @Download.prime=no as that will stop the script checking if the artwork exists before it asks kodi to perform the download ("priming" the download seemed to help improve reliability of imdb.com artwork downloads, although it could be a placebo...). Also, the script will ask kodi to download artwork up to 3 times by default, so this could also be blowing the fanart.tv rate limit (it depends where you added the delay, I suppose - between artwork items, or between web requests etc.). You could try @Download.retry=0 to avoid retrying failed downloads, and (in combination with the previous option) see if that helps avoid restarting the script (I've no idea why restarting the script helps, other than to introduce a sufficiently long enough delay to avoid immediately hitting the fanart.tv rate limits again).

The problem with implementing per-site rate limiting is really to do with the multi-threading as that makes it all a bit more complicated - per-site limits could be implemented, but it may mean enforcing a single thread just to simplify things. And when sites do implement rate limits they don't usually make public what those limits actually are - fanart.tv is quite unusual in providing the limits they have implemented. I'm fairly sure imdb.com implement some sort of rate limiting, but the exact details are unknown (at least to me). So configuring per-site limits would just be a guessing game, and crossing fingers, and I'm really not sure that there is a good solution for this issue other than the sledgehammer "1 request per second using a single thread".

Edit: Those options are @ download.prime / @ download.retry (lower case d - use the @ on the command line, leave it out when adding to texturecache.cfg). Unfortunately there's a @Download user (capital D) and the forum software in it's infinite wisdom decides to rewrite the message. Bah.

I dumped and re-scraped my full library this weekend and ran into issues with fanart.tv blocking requests from texturecache.py (503 errors after the first 20-30 artwork download requests).  I was able to work around this by setting download.prime=no and download.retry=0 in texturecache.cfg, and then added time.sleep(0.5) to line 1110 of texturecache.py v2.5.4.  This slowed down the requests from texturecache.py enough to avoid getting blocked. 

Would it be possible to make any modifications to the official version of texturecache.py to avoid this workaround?  It looks like the script already limits requests to fanart.tv to a single thread, so could requests to that domain be rate limited as well?  It's not ideal to have to slow down these requests so much, but the alternative is to run the script, kill it once requests start getting blocked, then restart the script. This can be a tedious process if thousands of items need to be cached.