Core: Emby doesn't work if the PC starts off

[azeos]

The problem

I have a PC with an Emby server and player. I successfully configured Emby in my HASSIO and it's working fine.

Sometimes that PC is turned off, and if my HASSIO starts _before_ that PC it's turned on, then the "emby player" won't get listed as an entity and an error is thrown.
Once that happens, even if I turn on the PC, the entity won't appear. The only solution is to restart HASSIO.

If the PC is on, and Emby isn't open, it won't get listed either, but no errors will show up. As soon as I open Emby, it gets listed as idle and if I close it, it goes off. And if I turn off the PC, it stills get listed as off.

HASSIO is always turned on, it's on a RPi 3a, but sometimes I restart it, the power goes off or for whatever reason the above situation occurs.

Environment

• Home Assistant Core release with the issue: 0.108.6
• Last working Home Assistant Core release (if known): Don't know, I think it never did.
• Operating environment (Home Assistant/Supervised/Docker/venv): Home Assistant in a RPi 3A.
• Integration causing this issue: Emby.
• Link to integration documentation on our website: Emby.

Problem-relevant configuration.yaml

media_player:
  - platform: lg_netcast
    host: !secret tv_host
    access_token: !secret tv_token
  - platform: emby
    host: !secret emby_host
    api_key: !secret emby_key
    ssl: true

Traceback/Error logs

Logger: pyemby.server
Source: __main__.py:342
First occurred: 20:38:42 (2 occurrences)
Last logged: 20:38:42

Error fetching Emby data: Cannot connect to host *local-ip:port* ssl:None [Connect call failed ('*local-ip*', *port*)]
Unable to register emby client.

Additional information

I also have a LG TV integration. When it's off, the WiFi is off so -I assume- HASSIO can't connect to it either, but nevertheless it appears in the entity list with an off state.

I'm expecting the same behavior with Emby, to always get listed. Is that possible?

Thanks,
azeos.

[probot-home-assistant[bot]]

Hey there @mezz64, mind taking a look at this issue as its been labeled with a integration (emby) you are listed as a codeowner for? Thanks!

[mezz64]

Emby is a client/server system. Home assistant needs to be able to contact the server during start to validate the config, setup a constant socket connection, and get the list of devices/clients, there isn't a retry mechanism for the initial server contact, only lost connections once a known valid config has been initialized.

It sounds like you run both a client and server on the same PC and the server likely auto starts in the background when your PC starts up. That's why your second scenario of the idle listing happens and once the initial handshake has occurred the component will retry (with an escalating delay) to re-establish a connection.

[azeos]

Your description is correct.

Is there anything that I con do/try? You mention that there are _lost connections_ when a valid config has been initialized. May be fake that first handshake? Or store the response somewhere? It's always the same static IP.

I don't know how it works, just some ideas. My python it's a little bit rusty, but if you point the direction, I could try something.

LG Netcast have another approach or that example doesn't work here?

Thanks!

[mezz64]

You can't fake the first handshake because you need to know what devices the server has available in order to initialize things. Only potential change is some kind of continued retry on the initial setup, but I don't know if that's something any other components implement. The closest comparison to emby is Plex and from what I can tell it performs the same way. The server needs to be available when home assistant is started in order to properly initialize.

[azeos]

I understand, don't know if in each handshake the response changes or not.

A continuous retry could work. But what about a _command_ to do the retry? I mean, my PC starts off and an event is triggered when it turns is on, I could run a command to retry the Emby connection then.

I mean, if no error is thrown when the server is off, but just the connection doesn't happen, can I somehow manually retry?

Thanks again for your response.

[jjlawren]

The closest comparison to emby is Plex and from what I can tell it performs the same way. The server needs to be available when home assistant is started in order to properly initialize.

It used to, but Plex now retries on startup: https://github.com/home-assistant/core/pull/32071.

Raising PlatformNotReady will use the built-in retry mechanism. Check androidtv for another example.

[mezz64]

Thanks @jjlawren. I'll take a look at implementing that into the Emby component.

[skank01]

Hi,

I think i have +- same issue? Not sure. (i'll try to explain in english, but its not my foreign language)
I got emby server running on my unraid server (which is not 24/24 available)
I got a dedicated vero 4k player which is the emby client. (not on 24/24)
Im running home assistant on rpi4 which is on 24/24

When the server is on, and HA is started (vero 4k also on) everything is working as expected and the emby state in HA is showing playing.. when playing movie.
When i shut down my vero 4k (emby client), the emby mediaplayer = vero4k is still showing available, although its not)
But it remains that way for a long time, unless i restart HA then it shows its correct state.
The other way around i have too. When its normal state is shutdown in HA, and i turn on my vero 4k it remains unavailable for a long time (dont know how long) , so my automations dont work. Unless i restart HA , all works again

@mezz64

[skank01]

Anyone?

[mezz64]

Your issue may be the same, but it's hard to tell from your description. Basically, if the HA device and the emby server device are on, then client states should be shown correctly. If the emby server is off somewhere in the mix, the client state is going to be incorrect.

The use case considered when writing these components is that both the HA computer and Emby server are always on and available. I'd like to address the retry issue at some point, but simply have not had time lately.

[skank01]

Ok...
if u want i can test a lot of stuff to to help you figure it out...

As i said, my HA is on raspberry pi (24/24 on) , my emby server is on unraid not 24/24 on..
My mediaplayer (emby client) is a vero 4k machine which also isnt 24/24 on, but if thats the problem i can probably keep it 24/24 on... but in standby if that would fix smth

When turning back my unraid (emby server) and vero 4k (emby client) on... i have to restart HA or it wont work

Really annoying

[skank01]

Your issue may be the same, but it's hard to tell from your description. Basically, if the HA device and the emby server device are on, then client states should be shown correctly. If the emby server is off somewhere in the mix, the client state is going to be incorrect.

The use case considered when writing these components is that both the HA computer and Emby server are always on and available. I'd like to address the retry issue at some point, but simply have not had time lately.

Is this something you will look into, in the future?
Since im making automations depending on the state of the player.. its pretty annoying they done work cause the state isnt correct, if you know what i mean

[mezz64]

I plan to update the Emby component to the config flow model that will support connection retries after HA has been started, just need to find the time to do it.

[skank01]

ok
This is the same as Emby integration not working: showing unavailable state #36512

[skank01]

I plan to update the Emby component to the config flow model that will support connection retries after HA has been started, just need to find the time to do it.

I would appreciate that a lot.
Theres no temporarily workaround now so my automations work?

[mezz64]

At the moment the only solutions are either leave the Emby server on 24/7 or always make sure the Emby server is started before HA is started. It can gracefully recover from lost connections after the initial connection is established.

[skank01]

Leaving server on is not an option.
Making sure emby server is started before HA is started,makes me think :)
I could setup an automation as soon as my unraid server comes on (which has the emby server), HA should automatically restart..

In that way emby server is started before HA is...
That could solve my problem i think, in awaiting you have to time to fix this.

[skank01]

Any chance this will be pickup at some time?

[mezz64]

@skank01 Unfortunately I don't have much free time these days to work on it. I'll happily accept any needed PR's on the underlying library if something needs tweaked for someone else to make the code changes though.