[#389] Fix for "Too many open files" media issue. #390

Merged
blacklight merged 4 commits from fix-too-many-open-files-during-media into master 2024-04-17 04:08:11 +02:00
Owner

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.

Closes: #389

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. Closes: #389
blacklight added 1 commit 2024-04-15 23:04:41 +02:00
[#389] Possible fix for "Too many open files" media issue.
All checks were successful
continuous-integration/drone/push Build is passing
33d4c8342d
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.
blacklight added 1 commit 2024-04-16 00:14:28 +02:00
Unregister a Zeroconf instance if it already exists before publishing a backend service.
All checks were successful
continuous-integration/drone/push Build is passing
4972c8bdcf
`mdns` connection are another culprit for the increasing number of open
files in the process.
blacklight added 1 commit 2024-04-17 02:51:55 +02:00
[media.chromecast] Resource clean up + new API adaptations.
All checks were successful
continuous-integration/drone/push Build is passing
f99f6bdab9
- `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.
blacklight added 1 commit 2024-04-17 04:00:01 +02:00
[media.chromecast] Refactored implementation.
All checks were successful
continuous-integration/drone/push Build is passing
e123463804
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.
blacklight merged commit 51a9b956bf into master 2024-04-17 04:08:11 +02:00
blacklight deleted branch fix-too-many-open-files-during-media 2024-04-17 04:08:11 +02:00
Sign in to join this conversation.
No description provided.