Plex discovery causing trouble?

HI,

I think since 101.3.Plex is being discovered all the time, even while I have already set it up manually in the config, according to the docs. Since Plex has been added to the config flow of integration, I keep getting the new integration has been discovered.

More over, I suspect it to be the cause of a nightly halt of the system, because the server which runs my Plex server is shutdown automatically at 00:30, and restarts in the morning, to keep power usage down ars much as possible.
I fear the Plex integration is flawed somehow, though I cant check the logs, because they simply stop at 00:30 and a bit…

All I can do is ssh in to the HA instance and do a ‘hassio ha restart’.

Anyone else experiencing issues with the new Plex?
any suggestions how to prevent this from happening, exclude it from the discovery process?

It shouldn’t be there in the first place, so might this be a bug?

thanks for having a look.

The Plex integration aborts discovery if it is already configured, but a persistent notification is still created by the discovery component and displayed in the UI. It’s an annoying cosmetic issue at the moment. Also see https://github.com/home-assistant/home-assistant/issues/27816.

Thanks.
Taking out Plex in the config, and having it installed through the integration solved both my issues though. The persistent notification has stopped, but as you said that was more of an annoyance.

The other issue has been a major flaw, and luckily hasn’t been seen after taking it out of the config.
Still see that as a bug…

Are you saying the integration stops updating if the Plex server shuts down?

well, to be precise, after the update, I experienced system unresponsiveness/halts in the morning, and, checking the logs, which stopped at the same time the Plex server got disconnected, I must indeed conclude that. At 00:30 my server is timed to power down until power at 6:30.
This apparently is reason for the Plex config to cause havoc, when configured via the config setting (opposed to via the integration)

It hadn’t done that before, and I hadn’t changed the settings for Plex or my server since ages, so the second conclusion would be it had to be the HA update (and updated code for Plex?) causing this.

I have taken out the config setting, and have only the integration setting in operation, which seems to work fine.

There shouldn’t be a difference in how the integration behaves based on how it was configured. Both methods create a config entry which is then used to start the integration.

If this happens again or is reproducible somehow, debug logs would be very helpful:

logger:
  logs:
    homeassistant.components.plex: debug
    plexapi: debug
    plexwebsocket: debug

Finally, I’d suggest to use 0.102.2 as a startup race condition has been fixed. I don’t see how that could cause the problem above, but the old behavior was a bit broken.

1 Like

thanks, did all you requested, and will post if anything arises again. Though, since I now have Plex setup via the integration, expect it not to cause issues any longer.

well too bad. happened again. And it is plex, only thing in the log for 15 minutes, then the HA instance stops being alive (though it it still online, I can see it on the network creating traffic:

2019-11-27 00:30:11 DEBUG (MainThread) [plexwebsocket] Websocket disconnected
2019-11-27 00:30:17 ERROR (MainThread) [plexwebsocket] Websocket connection refused: Cannot connect to host 192-168-1-81.9a8463redactedda.plex.direct:32400 ssl:None [Connect call failed ('192.168.1.81', 32400)]
2019-11-27 00:30:28 ERROR (MainThread) [plexwebsocket] Websocket connection refused: Cannot connect to host 192-168-1-81.9a84636redctedda.plex.direct:32400 ssl:None [Connect call failed ('192.168.1.81', 32400)]

so it indeed doesn’t matter how it Plex is configured…

what makes it awkward is I have another HA instance, and have Plex configured via the integration also, and that instance doesnt stop being responsive, and the log is filled with the same line until wakeup-time again…

Why this kills one instance and doesn’t kill the other is to be found out…
or… maybe it proves this isnt the Plex integration, and I should look into the Diskstation connection?

not sure how to set the debug setting to the correct level for that.

 homeassistant.components.synologydsm: debug 

?

I don’t see how the Plex integration could cause hangs or deadlocks. The reconnect logic is asynchronous and should not block. I would recommend looking at other integrations which could cause the hang.

The reconnect logic retries every 10s, so it would probably be better to have some back-off logic so it’s less noisy.

Agreed, that would be very welcome !

Who to talk to?

Me. Updated the library, it’ll be in a future release.

1 Like

So sorry, hadn’t realized you were the code owner…
Thanks!
FYI, I know we had these repeating ‘errors’ in the log for the Life360 component (at that time still custom) and Phil then had the component check for repeating errors after which a final one is created stating so, and waiting for the component to be back up.

Could be useful to have a scheme like that here also?
Anyways, thanks again !

It’ll just back off the reconnect delays instead of a fixed 10s interval:

2019-11-27 14:47:51 DEBUG (MainThread) [plexwebsocket] Websocket disconnected
2019-11-27 14:47:56 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 10s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connect
 call failed ('10.0.0.1', 32400)]
2019-11-27 14:48:06 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 30s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connect
 call failed ('10.0.0.1', 32400)]
2019-11-27 14:48:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 60s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connect
 call failed ('10.0.0.1', 32400)]
2019-11-27 14:49:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 120s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connec
t call failed ('10.0.0.1', 32400)]
2019-11-27 14:51:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 240s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connec
t call failed ('10.0.0.1', 32400)]
2019-11-27 14:55:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 300s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connec
t call failed ('10.0.0.1', 32400)]
2019-11-27 15:00:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 300s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connec
t call failed ('10.0.0.1', 32400)]
2019-11-27 15:05:36 ERROR (MainThread) [plexwebsocket] Websocket connection refused, retrying in 300s: Cannot connect to host <PLEX_SERVER_HOSTNAME> ssl:None [Connec
t call failed ('10.0.0.1', 32400)]
2019-11-27 15:10:36 DEBUG (MainThread) [plexwebsocket] Websocket connected

I see. Guess that’s very nice to start with and much better.
Still a bit of a brute force method, opposed to checking for the server to be online? If not , no use for trying to reconnect …?

fyi this is the solution for Life360 by @pnbruckner Life360 Device Tracker Platform

Retrying the connection is the way to determine if the Plex server is back online. The reconnect logic will gradually fall back to 5m intervals if it remains unavailable. This seems like a reasonable balance.

There’s no unique values in the messages, so the frontend will coalesce them.

sure, and as said, grateful for this.
please let me illustrate what I meant with brute force, and checking for server being online, with these 2 sets of quasi automations.

reconnect_plex_brute_force:
  trigger:
    platform: time_pattern
    minutes: 5
  condition: []
  action:
    service: script.connect_plex

and

reconnect_plex_when_server_online:
  trigger:
    platform: state
    entity_id: binary_sensor.server_online
    to: 'on'
  condition: []
  action:
    service: script.connect_plex

disconnect_plex_when_server_offline:
  trigger:
    platform: state
    entity_id: binary_sensor.server_online
    to: 'off'
  condition: []
  action:
    service: script.disconnect_plex

of course this is not functional but I hope you see what I mean. Wouldn’t that prevent hours and hours of useless errors in the logs, let alone efforts to try and reconnect, when the system in fact knows (should know) that is not possible in the first place?

as an extra info:

all of this trying to reconnect doesnt happen if I startup HA after the server has been powered down. Apparently the Plex component isnt activated in that case, and is completely silent, until server wakeup.

Which seems to indicate it should be possible to have that also happen after a server disconnect?

I think you’re describing a very uncommon usage case. It’s possible to add custom services which enable/disable the integration, but that’s pretty low on the priority list.

You can always just change the logging level of the plexwebsocket module and you won’t see any of the messages:

logger:
  logs:
    plexwebsocket: critical