search

jellyfin / jellyfin-plugin-dlna

GNU General Public License v3.0
15 stars 12 forks source link

DLNA not discoverable with Plugin 2.0.0.0 and JF 10.9.3 #55

Closed iwch closed 3 months ago

iwch commented 4 months ago

Hi, I'm trying to use the DLNA functionality of Jellyfin in a reverse proxy + ipvlan/macvlan setup in Docker. Specifically, I'm running nginx as a reverse proxy to access my instance via the internet, which means that I do not want to use host networking for the Jellyfin container (which is running the official jellyfin/jellyfin:10.9.3 image). I also want to use DLNA to play stuff on the local network. This was working fairly well in 10.8.13, using a macvlan docker network. Unfortunately, 10.9.x releases seem to have broken it, and I'd appreciate some help to get it working again. My machine information and the relevant bits of my docker-compose.yml are below:


It seems like my jellyfin container is assigned 192.168.1.2 in this setup. I can ping 192.168.1.2 from a different machine without problem, and it even shows up in my router's management console. However, no DLNA client seems to be capable of finding it. A quick `docker-compose logs jellyfin | grep -i dlna` suggests that the DLNA plugin is correctly finding the 192.168.1.2 address associated with the macvlan interface:

jellyfin | [23:59:33] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly Jellyfin.Plugin.Dlna.Playback, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null from /config/plugins/DLNA_2.0.0.0/Jellyfin.Plugin.Dlna.Playback.dll jellyfin | [23:59:33] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly Jellyfin.Plugin.Dlna, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null from /config/plugins/DLNA_2.0.0.0/Jellyfin.Plugin.Dlna.dll jellyfin | [23:59:33] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly Rssdp, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null from /config/plugins/DLNA_2.0.0.0/Rssdp.dll jellyfin | [23:59:33] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly Jellyfin.Plugin.Dlna.Model, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null from /config/plugins/DLNA_2.0.0.0/Jellyfin.Plugin.Dlna.Model.dll jellyfin | [23:59:36] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded plugin: DLNA 2.0.0.0 jellyfin | [23:59:36] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 127.0.0.1 jellyfin | [23:59:36] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 172.31.0.7 jellyfin | [23:59:36] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 192.168.1.2



As a final remark, all networking and DLNA plugin settings are untouched in the Jellyfin web GUI.
ionutvilie commented 4 months ago

I might have the same problem, DLNA is not binding on all interfaces or at least the correct one. My config is kubernetes based with multiple components, and I use inet 192.168.100.220 to broadcast on the home network. Jellyfin itself is binding on all interfaces because I can see the UI on 192.168.100.220:8096 and also the routing via ingress works (10.x.x.x). This happened only after auto-update to latest version (not a best practice but I did not care that much :) )

https://github.com/ionutvilie/awesome-home-server/blob/master/ak1pro/prod/jellyfin/sts-patch.yaml#L14

root@jellyfin-0:/# ip ad | grep inet
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    inet 10.1.191.193/32 scope global eth0
    inet6 fe80::64a3:6ff:fe85:c107/64 scope link
    inet 192.168.100.220/24 brd 192.168.100.255 scope global net1
    inet6 fd14:b9ed:2835:623f:9001:17ff:fe5a:3f2f/64 scope global dynamic mngtmpaddr
    inet6 fe80::9001:17ff:fe5a:3f2f/64 scope link
root@jellyfin-0:/#

# logs
[09:36:06] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 127.0.0.1
[09:36:06] [WRN] [1] Jellyfin.Networking.Manager.NetworkManager: 127.0.0.1: Only loopback 127.0.0.1 returned, using that as bind address.
voltagex commented 3 months ago

I don't think this code is reliable (at least it's caused issues while debugging as well):

in RegisterServerEndpoints (where your "Registering publisher" log message is from)

        var validInterfaces = _networkManager.GetInternalBindAddresses()
            .Where(x => x.AddressFamily != AddressFamily.InterNetworkV6)
            .ToList();

This is asking the webserver what it's listening on, filtering out any v6 addresses and then using what it finds, or falling back to v4 localhost.

There's also similar checks for setting up multicast listeners, but I haven't managed to debug that far yet.

voltagex commented 3 months ago

To the author: it might be useful to let the user override both the listening and the multicast address used.

disgustipated commented 3 months ago

I'm having similar but im not sure its related to the networking details listed here as im using the host network in my docker container. i was able to reconfigure a separate container that worked last week, version 10.8.13 before the plugin for dlna, and it popped up fine on my lg tv.

disgustipated commented 3 months ago

Starting to suspect that this is because the uri being used is https. ill admit im poking around where im not sure what im looking at fully but i put some debug messages in RegisterServerEndpoint and found that the uri that is built includes the fqdn and https uri. havent been able to test building the uri without that yet but if i get some time this afternoon ill hack away at it a bit. this was the log output from the uri the plugin currently builds Jellyfin.Plugin.Dlna.Main.DlnaHost: uri is https://*myFQDNinPublishedServerURISetting*:443/dlna/c8b0ef14-a211-4026-9ade-5e9136a28ab4/description.xml

actually... im 100% sure this is related to the published uri setting. i just took that out of my config and docker compose and the server is now listed on my tv. i'll see if i can poke through modifying that published uri setting this afternoon which may fix this.

disgustipated commented 3 months ago

Heres a hacked together dll that seems to work with the published url set, i had to hard code 8096 as the port just for testing since i cant figure out yet where to pull that from in the config. since @iwch and the other two here seemed to have a slightly different report than what i was seeing, im posting this here if anyone else wants to test it and if it works for you ill make a pull request after i figure out how to pull the port from the network config. i used similar lines that were on this commit to set the uri https://github.com/jellyfin/jellyfin/pull/4729/commits/d69f2d7d7fd4209652878d84f811051e69fb45b2 Jellyfin.Plugin.Dlna.zip

I also just tested with VLC player and jellyfin is showing up for me now where it was not previously. I'm not even sure how dlna was working for anything with the last version if you had the published uri setting set.

disgustipated commented 3 months ago

Heres a zip with the dll to use until release and includes the port that is specified in main server config for http Jellyfin.Plugin.Dlna.zip

I also confirmed that removing the bind ip set in the main config will allow this to bind to other valid IPs, i also had modified the logging line to show the published uri. 

jellyfin  | [12:07:20] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 127.0.0.1 with uri http://127.0.0.1:8096/dlna/c8b0ef14-a211-4026-9ade-5e9136a28ab4/description.xml
jellyfin  | [12:07:20] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 10.16.0.240 with uri http://10.16.0.240:8096/dlna/c8b0ef14-a211-4026-9ade-5e9136a28ab4/description.xml
jellyfin  | [12:07:20] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 10.26.0.240 with uri http://10.26.0.240:8096/dlna/c8b0ef14-a211-4026-9ade-5e9136a28ab4/description.xml
jellyfin  | [12:07:20] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 172.18.0.1 with uri http://172.18.0.1:8096/dlna/c8b0ef14-a211-4026-9ade-5e9136a28ab4/description.xml

This should fix op's issue, as it did mine, not sure of the other one. To test that attachment drop the dlls in place in your docker container located in your mount location for example mine is /mnt/containers/jellyfin/config/plugins/DLNA_2.0.0.0/ Note that might prevent future plugin auto updates as doing that set my version to 0.0.0.... not sure

tataa36 commented 3 months ago

@disgustipated Could this still be this topic?: https://github.com/jellyfin/jellyfin/issues/4599 I'm on Jellyfin 10.9.6 (no docker) and DLNA plugin v2.0. In my case DLNA isn't working as long I have enabled HTTPS. Samsung SmartTV or Marantz AV receicer, both devices switches on when I would like to start playing. The player on Browser or App on Smartphone never starts then. But after DLNA switches on the receiver I can use its remote to select the preferred audio and start playing. As I use jellyfin from the internet side I would love to see it working together with HTTPS.

disgustipated commented 3 months ago

@tataa36 while it will likely fix the issue youre seeing, it does not enable https for dlna; quite the opposite in fact, as it forces the http uri scheme and sets the bind ip to the available valid IPs. This is similar to how the 10.8 version worked and align with the comments there in early dec 2020 discussing the need for http. Adding the capabilities for the newer upnp spec mentioned there i feel should fall under a different FR as this fixes dnla with published url set. with that value set on 10.9 using the 2.0 plugin, dlna was completely broken. Prior to my change, in my server I had the published url value set in the config and when i removed that the local dlna streaming worked. After my change I was able to set the published url and dlna streaming worked on my local ip.