Avoid logging graceful disconnect as error #987
Conversation
The chromecasts restart each night, and seem to generally do this by doing a socket shutdown of write leading to a EOF received by clients. No need to log this as an error
|
Next step would be to add some backoff on reconnect. Not verified this, but if they behave correctly (which I suspect they do) they remove their mdns entry either before or more likely after they disconnect. So we should hit the mdns backoff if we delay just a little. But not fully sure how to add that delay. |
|
Hmm. I wonder should we set stop()? Will something restart the thread again when a service is spotted? |
I've had lots of problems with this before. We need a solution which works well both when the restart is unexpected, for example a power cut, and when the device reboots normally. |
Please elaborate. Which thread are you talking about? |
|
I think debug level is way too quiet in case of an unexpected disconnect, info would be better. |
|
This is not unexpected. Its a gracefull requested shutdown from remote, which occurs nightly. We can have it at INFO, since that is hidden in HA by default. |
|
The point is, when we get a graceful disconnect (eof from remote), we should delay the reconnect untill either some set timeout or a mdns broadcast is seen. In case of a non graceful disconnect (socket RST), we can try to reconnect directly. |
If i understand correctly each client handling a socket is a separate thread. To wait for next mdns event i was thinking of stopping down the current client thread and restarting on next announce. But I'm not fully following the code yet. So baby steps. |
The chromecasts restart each night, and seem to
generally do this by doing a socket shutdown of
write leading to a EOF received by clients.
No need to log this as an error