search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.9k stars 30.97k forks source link

DLNA/UPnP Digital Media Server streaming does not work in an HTTPS Home Assistant environment #68279

Closed Abdull closed 2 years ago

Abdull commented 2 years ago

The problem

My home network has two DNLA media servers, Jellyfin and Fritz!Box.

HTTPS support in UPnP/DLNA is nearly non-existing, both in media servers (Jellyfin, Fritz!Box, ...) as well as in clients (VLC/Video LAN Client, Windows Media Player, foobar2000, MediaMonkey Audio, ...). This means that HTTP ("HTTP-without-S") is the only way for interactions between UPnP/DLNA devices/services/servers ("thingies"). Also, many UPnP/DLNA thingies fail when hostnames are used instead of the IP addresses.

On the other hand, Home Assistant can be set up with HTTPS and hostname, e.g. https://homeassistant.example.com (I'm using Let's Encrypt SSL certificates for my private network).

For quite some time, browsers don't allow to access unencrypted HTTP addresses from an HTTPS setting.

Unfortunately, currently, Home Assistant's DLNA integrations don't convert DLNA HTTP- and IP address-based URLs into HTTPS- and hostname-based URLs.

**This makes DLNA useless within HTTPS-based Home Assistant installations: streams are not playing, media images are not showing up:

image

I was able to hack around at least for my Jellyfin instance by configuring it the following way:

Jellyfin web interface -> Settings -> Dashboard/Admin -> Advanced -> Networking -> Firewall and Proxy Settings -> Published Server URIs: all=https://jellyfin.example.com

Or identically in /etc/jellyfin/network.xml:

<NetworkConfiguration ...>
  ...

  <PublishedServerUriBySubnet>
    <string>all=https://jellyfin.example.com</string>
  </PublishedServerUriBySubnet>

  ...
</NetworkConfiguration>

With this hack, the DLNA Jellyfin integration works inside my HTTPS-based Home Assistant installation - but then other clients (VLC etc.) don't work with this HTTPS- and hostname-based Jellyfin DLNA setup.

One idea for solving this issue could be have all DLNA server URLs converted/proxied by Home Assistant, similar to how Home Assistant's MJPEG camera integration does it with HTTP-without-S MJPEG streams: E.g. my MJPEG webcam http://192.168.178.4:8080, integrated with Home Assistant, can be accessed without problems via https://homeassistant.example.com/api/camera_proxy_stream/camera.ip_webcam?token=d53404aefea0c50eb28511225b0b458b0174926131e589e03e0e59b248bcf0ef

Some UPnP/DLNA example URLs

Example UPnP/DLNA URLs with HTTPS and hostname:

Example UPnP/DLNA URLs with with HTTP-without-S and IP address:

What version of Home Assistant Core has the issue?

core-2022.3.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Core

Integration causing the issue

DLNA Digital Media Server

Link to integration documentation on our website

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

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] commented 2 years ago

dlna_dms documentation dlna_dms source (message by IssueLinks)

probot-home-assistant[bot] commented 2 years ago

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

marecabo commented 2 years ago

Thanks for writing this detailed description, I'm facing the same issue.

I also tried to add my URLs of the DLNA media server to allowlist_external_urls in the general Home Assistant Configuration but this did not prevent the https-upgrade, as I thought it would.

homeassistant:
  allowlist_external_urls:
    - http://192.168.178.5
    - http://192.168.178.5:8096
    - http://192.168.178.5:8096/Items
    - http://192.168.178.5:8096/audio
ingoratsdorf commented 2 years ago

Same issue here with Plex Media Server, running the DLNA server. Both Home Assistant and Plex itself are running HTTPS but DLNA server onyl runs HTTP. Not sure if any client would even understand HTTPS, thus I don't think that Plex would be doing a lot of work on this just to support Home Assistant.

Is there an option of adding a kindof proxy within the integration so that not the browser itself fetches the resources via HTTP (as it cannot) but from Home Assistant that gets it from the DLNA server without going through the browser?

I am aware that you can add an exception for insecure content for Home Assistant, but some people may not want (or technically cannot) do this. ;-)

chishm commented 2 years ago

Thank you for the detailed bug report. I'm sorry to say that this is most likely going to be closed as won't-fix.

This is an unfortunate collision of old and new technologies. DLNA is based heavily on HTTP only, and many physical DLNA renderers will fail to load content from an HTTPS server. Chrome will automatically upgrade URLs from HTTP to HTTPS, so is it possible for you to serve Jellyfin DLNA on both? (HTTP for physical devices, HTTPS for web clients.)

I don't have any plans to add media proxying support to the dlna_dms integration. But you might be able to stick a HTTPS reverse proxy (e.g. nginx) in front of your HTTP-only DLNA server as a work around.

Aside: I do plan to add proxying of cover art at some point, to support browsing from external clients. However, this won't be sufficient to proxy full media files, which would need a streaming approach (rather than a simple resource cache).

github-actions[bot] commented 2 years ago

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.