Problems with URL Resolver with Kodi 17 RC3
When certain source links are selected, get the error source not found
This problem is only with Linux distribution - does not show up on Windows of same revision.
The problem is affirmatively resolved (no pun intended) by rolling back the script.module.requests back to 12.9.1
So there appears to be some compatibility issue with the latest version of that module in the Linux system.
Not sure if this has changed in RC4 or final release - still waiting for those to be released in the linux ppa's.
I can confirm this issue on Krypton on Ubuntu systems with script.module.requests 2.12.4 installed. I've also seen actual HTTPS failures in Kodi itself (i.e. via curl) with that version of requests installed. I've reproduced it on 2 different systems, 3 different times.
As you said, back-leveling to 2.9.1 consistently makes the issue go away.
Two confirmed users reporting this issue - no comment from anyone on development side? (Or even other users?)
I wasn't aware that URL Resolver was an official addon - what are the main addons you're using that are calling it? A
debug_log (wiki) might reveal all...
(2017-02-08, 23:20)Prof Yaffle Wrote: [ -> ]I wasn't aware that URL Resolver was an official addon - what are the main addons you're using that are calling it? A debug_log (wiki) might reveal all...
1) urlresolver is in the official repo.
2) The problem isn't isolated to urlresolver, it happens with https calls made from any addon via python (even ones not made via the requests module). The most visible of these to users though is via urlresolver. It doesn't always happen immediately, but once it does you can't stop it until you uninstall script.module.requests at which time it stops immediately.
3) As I mentioned in my previous post, it's not just python, once it starts to happen, I've seen curl https:// calls made from Kodi to google servers (i.e. youtube) fail in the same way with mysterious socket errors/hangs with the new version of requests installed.
4) In addition to this thread, I've had several other experienced users report it to me and they all solved it the same way: backlevel script.module.requests to 2.9.1.
I haven't reported it till now because I knew this was the response I would see. I can give you a log for it in 3 seconds if you want it, but it will contain banned addons. I'm not willing to remove them just to prove to you that there's an actual problem. (Note, due respect intended, just being honest.)
Understood. I won't open that can of worms, then.
So, look at it another way - what configuration would (might) show this issue with official addons? If URL Resolver is in the official repository then there must be other addons that rely upon it; similarly, if it's a curl/https issue, then other functions must have the same issue. If that highlights an issue in the core Kodi code then the problem would be valid irrespective of the addon that's calling the function, IMO. Without that, though, I'm not sure where we can go...
(2017-02-08, 23:36)Prof Yaffle Wrote: [ -> ]Understood. I won't open that can of worms, then.
So, look at it another way - what configuration would (might) show this issue with official addons? If URL Resolver is in the official repository then there must be other addons that rely upon it; similarly, if it's a curl/https issue, then other functions must have the same issue. If that highlights an issue in the core Kodi code then the problem would be valid irrespective of the addon that's calling the function, IMO. Without that, though, I'm not sure where we can go...
It might be reproducible using a strm file pointing directly to a https url. The problem is it'll need to be done in a machine that is already showing the problem which will then again need a log to show it happening. I'm fine with pming someone a log if they can over look the things they don't like. Otherwise I guess it'll have to wait for someone else.
I'm in the same situation as tknorris re the log
(2017-02-08, 23:30)tknorris Wrote: [ -> ]2) The problem isn't isolated to urlresolver, it happens with https calls made from any addon via python (even ones not made via the requests module). The most visible of these to users though is via urlresolver. It doesn't always happen immediately, but once it does you can't stop it until you uninstall script.module.requests at which time it stops immediately.
Note the important factor here is that it's not necessarily (indeed likely not) a urlresolver issue - as tknorris says those are just the most visible error reported
But since the issue is resolved by going to the earlier revision of requests module, (no change to the urlresolver) it would seem to suggest that the issue lies in that requests module
Perhaps a comparison of the two versions of scripts.module.requests - 2.9.1 vs 2.12.4 - might show the component that is different?
2.12.4 exhibits the problem, 2.9.1 does not.
Again, I have only seen this as a Linux platform issue, (ie not on Windows or LibreElec Amlogic systems) and the only one that required the rolled-back requests module
(perhaps @
tknorris can confirm if that perception is valid)
http://mirrors.kodi.tv/addons/krypton/sc....requests/
(2017-02-09, 02:33)DEcosse Wrote: [ -> ]2.12.4 exhibits the problem, 2.9.1 does not.
Again, I have only seen this as a Linux platform issue, (ie not on Windows or LibreElec Amlogic systems) and the only one that required the rolled-back requests module
(perhaps @tknorris can confirm if that perception is valid)
http://mirrors.kodi.tv/addons/krypton/sc....requests/
That mirrors my experience, though I don't have any windows systems to test on: only Ubuntu and Android.
For what it's worth, I was giving 17 a quick spin on one of my mint 18 laptops before I went all in and updated all my media boxes. During the upgrade, a bunch of addons failed to update including Helly's repo for the Xonfluence skin. (this was a few days ago and i nuked my .kodi dir and fell back to 16, so i no longer have logs). The add-ons that failed to update all puked out the curl "not found". After a successful manual wget of the xonfluence package via the url copy/pasted from the kodi error log, it dawned on me that everything that was failing to update were all SSL urls. At that point i just decided to stay on 16 for a while.
This post is more of a confirmation that it's not limited to the urlresolver; but also affects curl based addon updates.
(2017-02-14, 05:48)ronie Wrote: [ -> ]if you're experiencing ssl errors on linux, check if updating the python cryptography module on your system helps:
Thank you! @
ronie
Sorry for very late response.
This I believe has resolved it:
I had been on the 2.9.1 version of requests (which appeared to at least provide a workaround);
after installing 'pip' then 'cryptography' I re-opened Kodi, at which point the Requests module proceeded to update;
typically when it automatically update, it would fail and I would have to manually revert back to 2.9.1 requests again;
however even after this update, it looks like is all functioning correctly*.
* Only small sample test but would almost certainly have failed even with that - will update this post should it re-appear with further testing.
(2017-02-25, 03:22)DEcosse Wrote: [ -> ] (2017-02-14, 05:48)ronie Wrote: [ -> ]if you're experiencing ssl errors on linux, check if updating the python cryptography module on your system helps:
Thank you! @ronie
Sorry for very late response.
This I believe has resolved it:
I had been on the 2.9.1 version of requests (which appeared to at least provide a workaround);
after installing 'pip' then 'cryptography' I re-opened Kodi, at which point the Requests module proceeded to update;
typically when it automatically update, it would fail and I would have to manually revert back to 2.9.1 requests again;
however even after this update, it looks like is all functioning correctly*.
* Only small sample test but would almost certainly have failed even with that - will update this post should it re-appear with further testing.
I just did the same and will update here if it starts to fail again.
Problem returned - again had to revert back to 2.9.1 requests to have it work properly once more.
I noticed today on one of my other systems there was an automatic update to URLResolver - not sure if that will change anything - at this point is just an observation and not even sure if linux system has yet updated similarly and if/how/whether that will change things.
(2017-03-06, 01:46)DEcosse Wrote: [ -> ]Problem returned - again had to revert back to 2.9.1 requests to have it work properly once more.
I noticed today on one of my other systems there was an automatic update to URLResolver - not sure if that will change anything - at this point is just an observation and not even sure if linux system has yet updated similarly and if/how/whether that will change things.
So far for me, the crypto update had solved the issue. The urlresolver update shouldn't have had any effect.