Skip to content
This repository was archived by the owner on Jul 10, 2024. It is now read-only.

Conversation

@ejel
Copy link

@ejel ejel commented Jun 22, 2018

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.
@ejel ejel mentioned this pull request Jun 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant