Emby server discovery broadcast ignores network override setting

[m4tt0 0]

Observation: Local authentification procedure from Kodi emby media import add-on keeps failing, despite of correct user credentials

Expectation: Local authentification succeeds

Relevant log entries:
2021-03-20 16:28:46.360 T:12024 ERROR <general>: [mediaimporter.emby] error retrieving response from POST http://172.20.0.4:8096/emby/Users/AuthenticateByName: HTTPConnectionPool(host='172.20.0.4', port=8096): Max retries exceeded with url: /emby/Users/AuthenticateByName (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x000002BD13B28D30>, 'Connection to 172.20.0.4 timed out. (connect timeout=2)'))

Context:

• The Emby server runs in a docker container in bridge mode
• 172.20.0.4 corresponds to the IP of the Emby container within the bridge network
• The Emby server contains a setting to override the actual IP address of the Emby server, which is correctly set to the server IP address running docker and the Emby container within my LAN
• I've used wireshark to extract the discovery broadcast message from UDP port 7359 directly and it also shows the incorrect bridge network IP, but not the one defined in the Emby server settings.

Question: Is this a bug or some regression? Any insights appreciated.

[m4tt0 0]

For those, who run into the same issue: The developer of the media importer Kodi add-on has introduced a new setting in the add-on, which allows to manually override the Emby server IP address from there, too. This provides a viable workaround for the issue. 

I still don't understand why the Emby server does not broadcast the override IP address configured in the network setting, and consider this a bug, or at least, very non-intuitive. If it's not a bug, I believe the corresponding help text should be clarified, not to trigger false expectations. As such, I'm still hoping for a response/reaction here...

[Luke 42086]

Hi, this has been changed for the next release, so that if you've provided a custom address, then this is the one that will be broadcast. thanks.

[m4tt0 0]

Many thanks, @Luke. Much appreciated.