Open dagwieers opened 2 years ago
After experiencing this once more (with fix #936) you get the standard error box pointing at a possible network issue. What is strange here is that if I try it a few more times it actually gets past the error fine. It is as if the device has network issues when being idle for some time and the first network-related activity gets a read-timeout. I have only seen this with the VRT NU add-on, but that is no surprise since it is the one I am using the most, and usually the first.
So looking at what is going on, I think we cannot improve it any further, except maybe the following three ideas:
Also, what surprises me is that I get the Timeout error almost instantly, whereas you would expect to get a Timeout error after some noticeable period of time has passed, so this might be something to investigate as well. Maybe something that can be tweaked from our side ?
Since you get the time-out almost instantly, I'm thinking about a too low timeout value in the code somewhere, like a value in ms instead of seconds or something?
I'll take a look, since version 2.5.7 a new favorites api is used. VRT deprecated the previous one
It seems this new api doesn't always return the favorites data that is requested.
The data is requested with get_url_json
from kodiutils just like we did before. It guess it's just this new api that behaves differently.
Describe the bug
It appears we are having these read timeouts quite often lately. It is unclear to me what is causing them, but maybe this is an opportunity to make our code somewhat more robust when this happens.
To Reproduce
Not sure how to reproduce it, we get it quite a lot since very recently.
Expected behavior
We now get a generic Kodi plugin error, whereas I would rather have it show there are issues with the connection, and include the Timeout error "The read operation timed out" as part of it.
Additional context
Log (if available)