[D-m-x]

Hi,

I'm having a strange problem and wanted to see if anyone else seen it, or even has a solution. I have two PI's with Libreelec setup and TMDB Helper 4.2.10. On both I have added the same OMDB API Key (which is working fine, I tried it via Browser), but I do receive in TMDB Helper Connection Error Messages (to OMDB API) so I'm not able to see some of the ratings. This is a snippet of the relevant log line, there's nothing more above or below that regarding this issue:

Code:

2021-01-28 14:52:30.282 T:1786553216  NOTICE: LoadJpeg: unable to load special://skin/extras/backgrounds/mountains3.jpg
2021-01-28 14:53:30.965 T:1583313792  NOTICE: script.xbmcbackup-1.1.3: scheduler enabled, finding next run time
2021-01-28 14:53:30.970 T:1583313792  NOTICE: script.xbmcbackup-1.1.3: scheduler will run again on 01-30-2021 03:00
2021-01-28 14:54:00.954 T:966783872  NOTICE: [plugin.video.themoviedb.helper]
                                            ConnectionError: HTTPConnectionPool(host='www.omdbapi.com', port=80): Read timed out. (read timeout=10)
                                            Suppressing retries for 1 minute

Naturally I would assume something is blocked/requests are not getting answered in time but I can query the api properly from both machines with a quick test:

Code:

Libreelec:~ # curl 'http://www.omdbapi.com/?i=tt3896198&apikey=myapikey'
{"Title":"Guardians of the Galaxy Vol. 2","Year":"2017","Rated":"PG-13","Released":"05 May 2017","Runtime":"136 min","Genre":"Action, Adventure, Comedy, Sci-Fi","Director":"James Gunn ..."

Additionally using ping to reach the host doesn't show anything unusual (response time wise).

Hitting the 1000 req/day limit should also be out of the question because I can query the api and receive information back (as seen above). I'm using the same with metadatautils and Arctic Horizon, no problems there.

Any idea? Would be appreciated.

So basically TMDbH suppresses retries to an API server for 60 seconds if it encounters connection issues. The suppression happens under one of three circumstances: (1) we get a 429 "Too Many Requests" response; (2) we get a 500 "Internal Server Error" response; or (3) the request times out after 10 seconds (which is what is happening here).

The main reason I suppress retries (rather than just dropping that specific request) is because generally these scenarios are ongoing and if we keep retrying with requests we just hold everything up but ultimately end up with the same result (no data because no response).

For (1), if we keep making requests we just extend the rate limit cooldown period, so it is better to stop and let it cool-off.
For (2), if the server is down, the server is down - hammering it with retries isn't going to make it come back up faster.

For the situation here (3 - timeout), I force the cooldown not because it is necessary but because if the server is slow it is generally better to load what we have rather than holding everything up because of network congestion. FYI - the timeout only happens with server/network congestion - you'd get a 400 unauthorised error if it was due to hitting the request limit (or your api key was wrong).

The call from TMDbH asks for a lot more data than the basic standard call, so it is very possible that although the server is able to serve the simple request fast, there might be database congestion which makes serving the more complex response slower
'http://www.omdbapi.com/?i={imdb}&t={title}&y={year}&plot=full&tomatoes=True&r=xml&apikey={apikey}'

I have noticed in the past few weeks that there has been some timeout issues with OMDb. I could be less aggressive about suppression for timeouts as sometimes it is just a one off where only one particular request is slow. But I also figure for something as small as OMDb which doesn't have heaps of resources it is nicer to suppress requests and it give it breather rather than bombarding a clearly struggling server with even more requests - plus the suppression is only a minute, so its not like it is a long time to wait.

Thank you for the very detailed explanation, that is very helpful and also interesting! I didn't know they had trouble with the servers lately, but it does make a lot of sense. For fun I used the call you provided and tried it, works fine on my Pi's so I would assume this is solved, simply a server overload