When keeping long-lived websocket connection, after some idle time
the connection will go into a bad state. Calling send() cause no
response at first and then broken pipe error is raised on the
subsequent call. The cause is that there is no designated thread
to keep the socket alive.
A possible drawback is that for short-lived / one-off call a thread will still be created and thrown away. If you feel this is excessive one possible solution is to add another config flag for long-live connection and only create keep alive thread in that case. Although the flag will only be applicable to websocket implementation at the moment. Let me know how do you like to proceed.
Testing Done
Test configuration: Samsung TV KS8000, websocket-client 0.48
Verified with interactive mode samsungctl -i that after some idle time (1 mins, 5 mins), sending key commands now succeeds.
Verified that the non-interactive mode still works as before.
Tested with Home Assistant integration. Verified that the issue is also fixed in Home Assistant by sending some commands from UI, wait for 5 minutes, and send another command.
It'd be great if this change can be tested on different TV models but I only have one TV 😕.
When keeping long-lived websocket connection, after some idle time the connection will go into a bad state. Calling send() cause no response at first and then broken pipe error is raised on the subsequent call. The cause is that there is no designated thread to keep the socket alive.
A possible drawback is that for short-lived / one-off call a thread will still be created and thrown away. If you feel this is excessive one possible solution is to add another config flag for long-live connection and only create keep alive thread in that case. Although the flag will only be applicable to websocket implementation at the moment. Let me know how do you like to proceed.
Testing Done
samsungctl -ithat after some idle time (1 mins, 5 mins), sending key commands now succeeds.