Problem when restarting Home Assistant and Kodi is standby or Off

[03397]

The problem

After the upgrade to the newest version 2022.6.x when I restart home assistant I am getting this warning message seen below This causes the Kodi not to have the power button on the card.

This is happening also when I shutdown Kodi this causes again the power button to be disappeared even if I can start kodi since it is in standby giving me the warning message.

This is happening because my Kodi is in standby so home assistant cannot actually communicate it that is why the message. But not all the Kodi are always on it's more reasonable to be in standby.

2022-06-05 10:12:38 WARNING (MainThread) [homeassistant.components.kodi.media_player] Unable to connect to Kodi via websocket

What version of Home Assistant Core has the issue?

2022.6.2

What was the last working version of Home Assistant Core?

2022.5

What type of installation are you running?

Home Assistant Core

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[Smiggel]

Same issue here.

Also having the issue dat one installation is not detected while the other one is. Same installation. In fact. The installation that is working, is actually a SD card copy of the one that isn't working.

[probot-home-assistant[bot]]

Hey there @onfreund, @cgtobi, mind taking a look at this issue as it has been labeled with an integration (kodi) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

---

kodi documentation kodi source _{^{(message by IssueLinks)}}

[nzhook]

I think this is the same issue I am having, I have Home Assistant turn off the NUC's that run the Kodi instances when I wont be using them (eg. at work) to save power. I have a turn_on device event which turns on the TV, Sound system, NUC and then waits for Kodi to come online which was working fine in 2022.5.

However in the latest update (2022.6.0) once the instance has been turned off the Kodi instance is marked as Unavailable (which is technically correct) but the option to turn Kodi back on is no longer available so the turn_on device event cant be triggered to turn it all back on again. This affects Lovelace as well interaction via Google Home.

I also have the same message a little while after the turn_off event automation runs: 2022-06-09 10:32:44 WARNING (MainThread) [homeassistant.components.kodi.media_player] Unable to connect to Kodi via websocket

But this should not make it unable to turn back on.

Also, to aid in debugging could the IP or device name be added to that message please.

[Smiggel]

In my case both kodi installations are on 24-7. It are Raspberry pi installations with Libreelec.

[Eljono]

Getting the same: WARNING (MainThread) [homeassistant.components.kodi.media_player] Unable to connect to Kodi via websocket

[nzhook]

Thought I would provide an update on the issue I gave detail about, after upgrading to 2022.6.6 for another problem, the issue I had with Kodi not being available to turn on once it goes unavailable is no longer occurring. Looks like the change that caused the problem was reverted in 2022.6.3 and I had not noticed. If your still having the original issue, try an update of Home Assistant.

[drewancil]

I don’t see anything in the release notes, but I can confirm it also is working for me as well. My HA restarts are much, much quicker now.

[03397]

@drewancil @nzhook After the upgrade I confirm that the power button is back. However, the warning is till there. As I have already mentioned it occurs when I restart home assistant and Kodi is in standby.

Does anyone have any similar issues?

[nzhook]

@03397 I do get that log entry still when the Kodi instance is offline (on start or after turning the instance off), but as the instance is offline it would make sense that it cannot connect to the web socket so its seems like a valid warning.

@drewancil I also missed it, but it sounds like the release note of 'Remove available property from Kodi' on .3 was the fix

[03397]

@nzhook I understand what you are saying but most of the Kodi are in standby. This started happening from some version forward.

[03397]

Guys, any new on this? IS there a workaround until a permanent fix is released?

I do not want to leave Kodi tuned on all the time!!!

[quadhammer]

I wonder if it is possible to disable the integration, and then use some sort of automation to enable it after booting up?

[Taomyn]

Is anyone looking at this? This is making my HA almost unusable and I can't keep my Kodi online all the time as it's running on my TV with Google TV and so it's not always running.

[03397]

@Taomyn I do not think is anybody is looking that and not only that I believe that nobody will.

This is considered a normal behavior. Everyone had their Kodi on all the time!!!

[nzhook]

I don't think its that everyone else leaves their Kodi on, more that the main problem everyone was having has been fixed. For example my Kodi is powered down when I am working and then I use WOL to start it up. (and an automation that runs before I finish work / arrived home). My issue was the power button was disabled when communication stopped (Kodi went Unknown) and that has been fixed.

I think to get any further help on this issue you would need to give more detail as that log message is normal and is saying communication with Kodi has stopped (which would be correct if you have it sleeping), but it should not be preventing you from turning it on using normal methods.

[quadhammer]

It doesn't prevent it working if it's not on, but adding 2 minutes to the boot time is hardly ideal. No other integration has such a long timeout preventing HA loading, that I can see.

[03397]

@nzhook This was a joke. I know that not everyone do not leave their Kodi on.

That is why this message and the way it behaves it is not appropriate. The addon should not create a message everytime it tries to access Kodi. If kodi is unresponsive it does not mean that Kodi is down, it might mean that it is on standby. When you restart home Assistant, Kodi integration creates a delay if it not on.

[nzhook]

@03397 I am not the developer of the integration, but the message is only alerting you that nothing responded so its set the status to be powered off/unavailable, in the previous versions if your Kodi was not responding as it was in standby or offline nothing was logged which would have made diagnosing network problems harder.

Personally, none of my Kodi instances block Home Assistant from delaying the startup for two minutes, and they all only log once when the machine is not available or it gets powered off. If you are getting a delay you may want to turn on a higher level of debugging to see what integrations are loading just before that message is posted, and if it is Kodi then post that log so the developer can look into it.

I would also like to point out your original problem was: 'This causes the Kodi not to have the power button on the card.' are you running the latest version and is your power button showing now? as if it is your issue maybe with the automation that takes your Kodi instance out of standby.

[quadhammer]

Logger: homeassistant.bootstrap Source: bootstrap.py:441 First occurred: 5:26:12 PM (2 occurrences) Last logged: 5:27:12 PM

Waiting on integrations to complete setup: kodi

[mvn23]

I tried to look into this as I am affected by this issue as well. On my main install at home the initial connection attempt on the line below takes exactly(!) 60 seconds down to the millisecond, however I can see that the underlying library is setting a timeout of only 5 seconds. https://github.com/home-assistant/core/blob/9ed629d838ba4bbff87e8de9870a3d8875eb49a6/homeassistant/components/kodi/__init__.py#L47

Weird thing is, when I try to reproduce the problem on my laptop the delay is not as noticeable and the connection attempt only takes around 6 seconds. I will look into it a bit more when I have time and provide a fix if I can track down the underlying issue. For now it seems like it's not a problem in Home Assistant, so it may need fixing in one of the libraries instead.

[h3llrais3r]

I have been digging in the code, and as far as I can see, it's coming from the aiohttp library. The client.py does not pass down the timeout when making the request, which makes the connection using the default timeout. See https://github.com/aio-libs/aiohttp/blob/master/aiohttp/client.py#L769-L779 When I'm passing down the timeout=timeout in this self.request the websocket connection respects the timeout. When this could be fixed in aiohttp, the connection timeout for kodi at startup should only take max 5 seconds...

Created bug: https://github.com/aio-libs/aiohttp/issues/7220

[h3llrais3r]

@OnFreund A workaround for setting the right timeout is setting it via the clientConnection instead of passing it via the connect. I've done some testing locally and when I'm passing the default timeout of 5s into the client connection within pykodi, the connection timeout seems to respect the 5s. Since you are the author of pykodi, can you provide the fix in pykodi? https://github.com/OnFreund/PyKodi/blob/master/pykodi/kodi.py#L31 should become self._session = aiohttp.ClientSession(timeout=aiohttp.ClientTimeout(total=timeout))

I've tested this with the following code (use IP that is not accessible to simulate that kodi is not available):

import asyncio
import time
from pykodi import CannotConnectError, get_kodi_connection

DEFAULT_PORT = 8080
DEFAULT_SSL = False
DEFAULT_TIMEOUT = 5
DEFAULT_WS_PORT = 9090

CONF_HOST = '192.168.0.110'
CONF_PORT = 8090
CONF_WS_PORT = DEFAULT_WS_PORT
CONF_USERNAME = 'kodi'
CONF_PASSWORD = 'kodi'
CONF_SSL = DEFAULT_SSL

async def ping():
    conn = get_kodi_connection(CONF_HOST,CONF_PORT,CONF_WS_PORT,CONF_USERNAME,CONF_PASSWORD,CONF_SSL,timeout=5)
    try:
        start = time.time()
        await conn.connect()
    except CannotConnectError:
        end = time.time()
        print('timeout error after %ss' %(end - start))
        print('error')

asyncio.run(ping())

[OnFreund]

@h3llrais3r since the kodi integration passes the HA session, that branch isn't executed.

[h3llrais3r]

Ok... any way to adapt/clone the HA session and adding the timeout on it? Because I don't think there is currently a way to set the timeout instead of putting it on the session object. The connect doesn't pass down as mentioned in https://github.com/aio-libs/aiohttp/issues/7220

[OnFreund]

If you want to change the timeout for the HA session then that's a bigger change than just the kodi integration. I would suggest trying to socialize this with the core devs on Discord before creating a PR. Alternatively, you can try to create a PR with aiohttp to fix this.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[h3llrais3r]

Bump

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Ulrar]

Not stale

[krasatos]

Bumping as i have the same issue. I am integrating Kodi running on my pc and i have very slow HA startup when pc is off/sleep or kodi is not running.

[hcw70]

Similair / the same as #47828 ?

[Sian-Lee-SA]

I got sick of this issue today so went into the code and changed the following in __init__.py lines 47 and 59

    try:
        pass
#       await conn.connect()
    except CannotConnectError:
        pass
    except InvalidAuthError as error:
        _LOGGER.error(
            "Login to %s failed: [%s]",
            entry.data[CONF_HOST],
            error,
        )
        return False

    async def _close(event):
        pass
#       await conn.close()

Quick hacky solutiong but at the end of the day, it's going to try reconnect while Home Assistant is running so doing a connect at startup in a blocking thread seems a tad redundant. The code seems old too as I assume it should have a coordinator

[quadhammer]

Can we merge this into the main Home Assistant core library, if it works well?

As I'm running on a VM image, I don't think I have access to "homeassistant/components/kodi/init.py", I only have access if it is a custom component. Any ideas?

[Sian-Lee-SA]

Hardly merge worthy, infact the whole block of code could be removed as it's all redundant with nothing happening in the try block. To be merge "worthy" it would need some serious redifinements and should have a connection attempt on startup but in a coordinator while not blocking.

I use docker so it's easy to replace files but surely VM's images can be browsed and edited with the appropriate software or SSH'd. I used to use VM's alot until docker became my goto.

Edit: Also closing the connection when Home Assistant restarts is something that should hapen (good programming flow) but I think Home Assistant was slow on restarting because of the integration (didn't thoroughly check) but commented it out regardless because either way, the client will handle a deaad connection anyway.

[dolenec]

Any news.. Same problem as seen on https://github.com/home-assistant/core/issues/47828

🫣

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Ulrar]

Not stale

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[03397]

Not solved. Two years old. Guys, either do something or close it. There is no point in keeping this opened.

[dangel666]

Not solved, still :(

[Taomyn]

Please can someone look at this? It's beyond any other integration:

[Grandma-Betty]

I can confirm this is still an issue. Please fix this!

[quadhammer]

It looks like it has finally been fixed! Mine has gone from needing about 3 minutes to start, to 30 seconds.

Thank you for finally fixing this, kind Internet stranger(s)! :)