1/25/2024 0 Comments Emby client requirements![]() See the difference? The two that can’t resolve names lack the ndots option. The first three know how to resolve by name, the last two do not. Here are the results for all five containers. Knowing that three out of the five containers work, I searched for commonality and differences in this file: /etc/nf Success! I fixed it and (upcoming bold statement) believe it is due to an internal misconfiguration (i.e. I’m not sure how to fix those two containers. The critical one is, of course, the homeassistant container. Therefore out of the five containers just two don’t know how to resolve local host names. The test succeeded in all of them except hassio_multicast. I repeated the ping io test in these other containers: hassio_supervisor Whereas pinging by its IP address works: bash-5.0# ping 192.168.1.5 Pinging a local host by its name fails: bash-5.0# ping io I used portainer to open a command shell in the homeassistant container (which is, like all recent versions, running Alpine Linux). The situation is different within the homeassistant container. In addition, from the SSH shell I can successfully ping io (although I imagine that has more to do with how the underlying Ubuntu is configured network-wise). It’s already configured to use my local DNS exclusively (i.e. I may be wrong but I don’t think I need to do that because here’s the current output of ha dns info host: 172.30.32.3 After a restart, Home Assistant Supervised connected to the Emby server.Ĭan someone explain how to make the Supervised version recognize the local network’s DNS? Or is that inadvisable? I’ve modified the Emby integration’s configuration and replaced the hostname with its IP address. That means it uses my local network’s DNS whereas the Supervised instance apparently doesn’t. On the instance of Core installed as Docker, within its container it can resolve host names. In other words, within the Supervised instance, it cannot resolve host names on my network. I repeated the test from within the container of the instance installed as Home Assistant Core and was able to ping io successfully. I repeated the test and pinged io’s IP address and that was successful. Using portainer, I opened a console in the Home Assistant container and tried to ping the Emby server io. The solution proved to be trivial to implement but it made me realize that I don’t really understand Supervisor’s “network plumbing”. Have I missed a configuration step with Home Assistant Supervised or is this a bug in 0.109.X? From the machine hosting Home Assistant Supervised, I can ping the Emby server by its name (meaning it can resolve the hostname “io”). The configuration is simple and all three use the same API key (I even tried with a different API key but it didn’t fix the problem): media_player:Īll machines are on the same subnet network-wise, it’s all very vanilla. 16:03:32 ERROR (MainThread) Unable to register emby client. 16:03:32 ERROR (MainThread) Error fetching Emby data: Cannot connect to host io:8096 ssl:None Home Assistant Supervised 0.109.5 (Ubuntu).The one that fails to connect is the latest version: Home Assistant Core 0.108.3 (docker on Ubuntu).Home Assistant Core 0.103.2 (venv on Lubuntu).I have three instances of Home Assistant and one of them is unable to connect to the Emby server. Before I post this as an Issue in the Github repo, I thought I’d let the community take a look at it first.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |