DLNA Renderer breaks frontier_silicon integration entities

[muddy79]

The problem

I have four audio devices handled by fronter_silicon integration (3×Technisat, 1×hama). They have never been auto-discovered, so I added entries to configuration.yaml

media_player:
  - platform: frontier_silicon
    host: x.x.x.x.
    name: hama_xxxx
    password: 1234

Unfortunately, after upgrading to 2022.07, media_player entities has disappeared. Instead, DLNA Media Renderer devices have been auto-discovered, with different (auto-generated) names. The devices became unusable, since I am not able to call media_play, media_toggle etc. services on them. I have no idea how to fix this issue: even after removing the auto-discovered device, the configuration.yaml input is ignored.

What version of Home Assistant Core has the issue?

2022.7.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

dlna_dmr

Link to integration documentation on our website

https://www.home-assistant.io/integrations/dlna_dmr/

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

[probot-home-assistant[bot]]

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

[probot-home-assistant[bot]]

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

[StevenLooman]

If the devices also support the DLNA DMR protocol, then it it will also be discovered by the dlna_dmr integration. However, I think your problem is that the frontier_silicon integration doesn't find the devices any more. This sounds more a bug with that integration.

[probot-home-assistant[bot]]

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

[probot-home-assistant[bot]]

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

[StevenLooman]

However, perhaps the discovery of these devices should be omitted by the dlna_dmr integration, as is done for Philips TVs for example.

[muddy79]

Just a hint: frontier_silicon devices allow only single "session": for example, once configured in ha, it's not really possible to use them in the official undok application.

[wlcrs]

Frontier silicon radios also expose themselves as DLNA devices. However, this should not interfere with the frontier_silicon integration.

Please double check your logs to find information on the integration failing to load.

@muddy79 the underlying library has been updated to not create a session if the radio supports this. I'm able to use UNDOK with my Roberts Stream 94i while the integration is enabled. However, for radios with older firmware I do a fallback to using a session.

[muddy79]

Unfortunately, there was no useful information in the log file (with DEBUG level). After removing DLNA_MR devices and two restarts frontier_silicon entities has appeared again. Maybe it's not really related to the DLNA_DMR, BUT I also have fifth device configured manually (hama IR360MBT), which is located remotely in a different network, so it is not auto-discovered by DLNA_DMR and it used to work all the time, while I had troubles with the ones in my network. All of them are quite old devices, without firmware upgrade for a long time... Anyway, It would be nice to have an "ignore list" for ANY auto-discovery.

I actually had similar issue with my Samsung TV a few days before: it has also been auto-discovered by DLNA_DMR and the "standard" media_player entity from Samsung TV integration has disappeared. I was able to recover it by removing DLNA_DMR entity for it.

[muddy79]

I guess this might be some sort of Loch Ness bug: maybe caused by some timing issues on fronter_silicon and dlna_dmr initialization / network or firmware quirks... Since nobody else experience it, I'll close the bug, until I have more useful evidence (like: logs).

[StevenLooman]

The ssdp component does als the UPnP related (thus components dlna_dmr, dlna_dms, upnp, ...) discovery. Though, this only works when the device can be talked to directly/is on the same network.

I doubt the dlna_dmr component interferes. The way it works is that the ssdp component does a discovery, and 'routes' the discovery to the relevant component. If a device advertises itself as it can do multiple things (i.e., dlna_dmr and samsung), it is preferred that the dlna_dmr component (in this case) ignores the discovery. The logic for this can be found here: https://github.com/home-assistant/core/blob/2b1e1365fdb3bfe72feb515fcf2e02331caa4088/homeassistant/components/dlna_dmr/config_flow.py#L367

The other component (i.e., samsung) still does receive the discovery through the ssdp component (or zeroconf, when applicable.)