continuous-integration/drone/push Build is passingDetails
Explicitly use a `CastBrowser` object initialized at plugin boot instead
of relying on blocking calls to `pychromecast.get_chromecasts`.
1. It enables better event handling via callbacks instead of
synchronously waiting for scan batches.
2. It optimizes resources - only one Zeroconf and one CastBrowser object
will be created in the plugin, and destroyed upon stop.
3. No need for separate `get_chromecast`/`_refresh_chromecasts` methods:
all the scanning is run continuously, so we can just return the
results from the maps.
continuous-integration/drone/push Build is passingDetails
- `pychromecast.get_chromecasts` returns both a list of devices and a
browser object. Since the Chromecast plugin is the most likely culprit
of the excessive number of open MDNS sockets, it seems that we may
need to explicitly stop discovery on the browser and close the
ZeroConf object after the discovery is done.
- I was still using an ancient version of pychromecast on my RPi4, and I
didn't notice that more recent versions implemented several breaking
changes. Adapted the code to cope with those changes.
continuous-integration/drone/push Build is passingDetails
It seems that the process keeps a lot of open connections to Chromecast
devices during playback.
The most likely culprit is the `_refresh_chromecasts` logic.
We should start a `cast` object and register a status listener only if a
Chromecast with the same identifier isn't already registered in the
plugin.
Fabio Manganiello