-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
URLError: <urlopen error ('_ssl.c:710: The handshake operation timed out',)> #191
Comments
I would expect that requests would retry in some of the failure scenarios. |
That's right, but in the previous version requests got also timeouts. We can't fix bad internet. |
It happened again today a few times, and I have never seen this before myself that I can remember. |
I can't reproduce this issue. Does this only occur with |
The problem is that this is not easily reproduced. I haven't been collecting all the occurrences as I assumed it happened everywhere, but I should have some in my logs. Only one of my systems has not been rebooted since. This one happened once:
This one 4 times in quick succession (I remember trying a few times):
I am almost certain that in the second case the problem was related to the service, and not a local network issue. |
Now the first time I have seen this: SSLError: ('The read operation timed out',)
Happened a few times when trying to play a stream. |
I have not seen any incidents anymore myself, but let's keep this issue open a bit longer. |
I never ever got such an error. I really think it's related to a bad internet connection. |
@mediaminister What do we consider "a bad internet connection" ? IMO these were caused by issues at VRT infrastructure. I have also experienced a stream that stopped during playback, in one case the stream was unavailable for about 5 minutes before things worked again. Since I also do radio streaming continuously when I am working, I doubt I have an Internet connectivity issue. In any case, I haven't seen this ever before we switched to urllib2, so IMO Requests is more mature in handling these issues (whatever the cause). |
I consider failing requests caused by issues at IP level (client, ISP or server) as "bad internet". |
Sure, the problem is that it is not quite reproducible, but if it happens again for a longer period I'll try to troubleshoot. Again, I doubt it's related to the stuff I control myself. That said, I plan to look into injecting intermittent faults in my network with the intent of looking how the plugin behaves. But even for this it may be hard to reproduce the exact same issues, let alone have it automated. Version 1.9.0 has been released, we'll see if people report similar things. |
Ok, I haven't seen this once since those incidents. Let's close it and I'll look into injecting intermittent failures to make our plugin survive them better. |
And now I have seen this issue in TravisCI: https://travis-ci.org/pietje666/plugin.video.vrt.nu/jobs/535568744
|
All #817 builds passed in the TravisCI cloud, I don't find that ERROR there. |
No, I did a rebuild so the project shows the build is passing. It did fail in TravisCI. |
Alright, no incidents, no progress. Closing this again... |
This is problem of internet connection, no problem of this package. I have the same error in other tool:
If something can be done in code of this package this is handling of bad internet problems. |
@gustawdaniel If you intend to build a reliable solution, there are two possible points of view:
I reported it for the second reason, and because we had just moved from Requests to urllib2, and these issues were only seen after this move. For better reporting to the user, see #385. Even if there is no way to work around the problem, we could still offer the end-user a clue to why they have this problem. |
Describe the bug
I just got this error while testing the MNM stream
The text was updated successfully, but these errors were encountered: