use PublishedServerUrl as advertised host location

[brokenmass]

the DLNA plugin is ignoring the configured PublishedServerUrl when answering discovery request and returns, instead the ip address +port of the server.

If someone confirms that returning PublishedServerUrl is the correct behaviour i would be happy to raise a PR

[hornet-dev]

From old issues that were fixed when DLNA was not a plugin, this used to work. I can confirm that it doesn't seem to work with the latest plugin and released Jellyfin

[lfse-slafleur]

From what I can find in the DLNA plugin code, this is actually pointing directly to the network interface address instead of relying on the PublishedServerURI:

jellyfin-plugin-dlna/src/Jellyfin.Plugin.Dlna/Main/DlnaHost.cs

Line 267 in deab450

var uri = new UriBuilder(intf.Address + descriptorUri);

This is annoying as this indeed prevents our jellyfin server from being discovered across subnets.

[lfse-slafleur]

@crobibero I have never worked in C# before, but the fix appears tiny. If it helps, I can give this a go. My proposal would be to change the line I posted before to take the PublishedServerURL if available from netconfig or else default back to the interface address as happens now. Does that make sense?

Perhaps something a bit more fancy is necessary e.g. a toggle if the plugin ahould use the PublishedServerURL or not and I dont mind giving it a go, but I am very unexperienced in this language and code base so it might take a while xD

[brokenmass]

maybe just reverting https://github.com/jellyfin/jellyfin-plugin-dlna/pull/62/files is enough ?

// edit: no, doesn't look like.

i'll raise a pr later

[lfse-slafleur]

@brokenmass I attempted a fix with my receiver and setup and perhaps I understand why this plugin doesn't use PublishedServerURL. My AVR only accepted the SSDP UDP response with the LOCATION header set to a /24 ip. Even with the netmask set to /16 on the AVR and using ip addresses instead of hostnames, no joy. Also with an URL, no joy. HTTPS wasnt allowed either. The only setup it accepted was when the LOCATION was set to a /24 ip and the source ip was also on the /24 range and http was used. So perhaps in practice no URL's are used because no devices accept them and therefore this plugin forces you to use an ip. In this perspective, the current code makes a lot of sense. Would be great if @crobibero can confirm once they have the time.

EDIT: I am in no way an DLNA expert, so I am just sharing my findings. If an expert does come along, please correct my info if it is (partially) wrong.

[brokenmass]

maybe then using PublishedServerURL should be a configuration toggle

[brokenmass]

I did some reading and I think we can close this issue as:

• dlna v1.x does not support https (and publishedServerUrl is typically used when jellyfin is served behind a reverse proxy with https termination) (DLNA HTTPS ISSUE jellyfin#4599 (comment))
• some receivers only support ip (DLNA HTTPS ISSUE jellyfin#4599 (comment) / use PublishedServerUrl as advertised host location #156 (comment))
• dlna is a dead standard

the fix was actually simple : var uri = new UriBuilder(_appHost.GetSmartApiUrl(intf.Address) + descriptorUri); but with this change the dlna server is not recognised by windows (and EVEN IF windows supported the latest dlna standard, the effort of modernising the plugin to be fully compliant would not be worth the time)