Improve chromecast disconnection logic #14190
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
The latest cleanup to the cast platform introduced a weird bug where disconnecting from the old leader of a cast audio group was not handled correctly.
In particular, cast group leaders don't like accepting connections as long as there are open sockets to the old leader. In the old code, we would do a non-blocking disconnect and not join the socket client thread. So we tried connecting to the new leader before the old leader was disconnected. This prevented us from connecting to cast groups on every second leader change.
Apparently,
async_will_remove_from_hass
is not called onEVENT_HOMEASSISTANT_STOP
. With the assumption that this seems to be intended (feels weird to me), I manually added a listener to the event bus.If there's a 68.1 release, it might be good to maybe include this PR. It's not a huge code change and I spent the last few days testing this change.
Related issue (if applicable): fixes #13530
Example entry for
configuration.yaml
(if applicable):Checklist:
tox
. Your PR cannot be merged unless tests passIf the code does not interact with devices: