I was looking at the code in the for the webSocket threads and realized I could simplify it by re-arranging some things. I also added some logging to make it easier to see what's happening in the future if there are disconnects. I'll add some code to pass in a log function so we can remove the common.py dependency.
Anyway this seems to fix #13, though I'm not sure why :)
When I unplugged my Ouya (which causes the socket to disconnect pretty quick), the re-connection code worked fine (and it was easier to see with the added logging). I'll have to let it run for a while to make sure the original [Errno 104] Connection reset by peer I was getting before doesn't somehow still break it.
I also shortened the sleep time on in service.py for faster shutdown response. This doesn't seem to have an measurable effect on CPU usage, but I can set it back if you would like. I also made the reconnect sleep only wait for 100ms between abortRequested checks, which shouldn't be a problem since this isn't a long running loop.
I was looking at the code in the for the webSocket threads and realized I could simplify it by re-arranging some things. I also added some logging to make it easier to see what's happening in the future if there are disconnects. I'll add some code to pass in a log function so we can remove the common.py dependency.
Anyway this seems to fix #13, though I'm not sure why :)
When I unplugged my Ouya (which causes the socket to disconnect pretty quick), the re-connection code worked fine (and it was easier to see with the added logging). I'll have to let it run for a while to make sure the original
[Errno 104] Connection reset by peer
I was getting before doesn't somehow still break it.I also shortened the sleep time on in service.py for faster shutdown response. This doesn't seem to have an measurable effect on CPU usage, but I can set it back if you would like. I also made the reconnect sleep only wait for 100ms between abortRequested checks, which shouldn't be a problem since this isn't a long running loop.