Support reading port from SRV DNS record

[CorruptComputer]

Is your feature request related to a problem? Please describe. Login flow for servers using HTTPS with a non-default Jellyfin port is terrible, even when selecting a server from a local network. Having to type in the whole https://jellyfin.example.com:443 for connections is a terrible UX, especially on a TV where input is already painful.

When selecting from the list of servers on the local network it will just throw up an error that it can't connect to port 8096 on the server, which yeah I'm not using that port... How is it finding the server, but also not able to read the port its running on?

If I leave off the https:// and just do jellyfin.example.com:443, I get Error: [-3] as the message with no other explanation. The only thing I can assume here is that it is defaulting to HTTP over this port which will never reach my server since HTTP traffic is not being accepted on port 443 in my gateway.

Describe the solution you'd like If I could just type in jellyfin.example.com and have that be enough it would make the experience a lot better. One way to do this would be supporting SRV records on the domain, for example something like this would be what it would look like in Cloudflare:

Reading the port from the DNS record there makes the process a lot more simple to the end user, though it would be an extra (optional) step for the person setting up the Jellyfin server.

As for the HTTP/HTTPS issue, would it be possible to check if HTTPS is supported and if not fall back to HTTP for the connection?

Describe alternatives you've considered I could just port forward those default 8096/8920 ports, but I don't want to do that.

For me my network goes: Internet ---> Router ---ports 80/443---> Nginx Gateway ---depending on the subdomain---> Application VM

So if I forwarded those ports directly to the Jellyfin server it would bypass the Nginx Gateway I have setup and leave my network slightly less secure since the traffic wouldn't be going through the firewall I have configured there.

Additional context Ports configured in the Jellyfin network settings:

[dkanada]

For what it's worth most clients check the default ports already, but a SRV record sounds interesting and it might be useful to solidify a policy at the project level.

[nielsvanvelzen]

While I do see some benefits in the use of SRV records, in your specific case the issue is that Roku doesn't try to connect to the default ports (8096, 8920, 443 and 80) when the input doesn't specify a port/protocol. Our Kotlin SDK contains extra functionality to "normalize" server URL input^1 that can add the protocol/port and try suggest a set of URL's to try to connect to based on the input. We should probably document this behavior so we can make it consistent across different clients.

[CorruptComputer]

Thanks for the replies, I'm not sure why this issue was moved off of the Roku repo. The problems I have are specifically with that app, and the android app and website both work as expected with me just being able to type in jellyfin.example.com and it works.

Though I guess it could be helpful to document the SRV record at a project level since that would make it easier for all clients to conform to it.

[oddstr13]

(m)DNS-SD is something I've been advocating for a long time, but I haven't found the time to prioritize it myself yet.

I did a quick search but didn't find an issue so it's possible I've only mentioned it in chat (please link here if you can find related issues tho).

[dkanada]

@CorruptComputer that's exactly why I ended up moving it, the SRV record isn't implemented anywhere so it seemed like more of a project discussion. Roku would definitely benefit from adding the default port check though.

[joshuaboniface]

I agree with adding some frameworks around SRV records. Lots of modern protocols are adding them to make autodiscovery in more advanced environments than "a LAN" easier. Then someone can just enter a simple domain and get to the right place, and it would be completely optional for administrators to configure.

There's really 2 parts to this that I can see:

1. We establish some sort of standard for what kind of SRV record we should use. The standard for SRV records is:

_service._proto.name. ttl IN SRV priority weight port target.

and following that convention, _jellyfin._tcp.<domain> seems sensible, where <domain> is what the user would enter in a client.

2. Clients would need to support this. I don't think there's anything we'd actually need to do on the server side (though maybe the web client(s) could use it too?). I would guess the easiest path would be to take the user input, do a SRV record query first, and if that fails then do other stuff like auto-check ports, and then fail out if nothing matched. I think the SRV should come first so it would override basic autodetection, but this would be up to each client to decide on.

[sevenrats]

SRV records are cool but fwiw the Roku client is supposed to be doing this: https://github.com/jellyfin/jellyfin-roku/blob/5dbbc98c0fbfd2fd79c8eb9772ed507747b3dc5f/source/utils/misc.brs#L169 If it is not working please file a bug report against the Roku app.

[CorruptComputer]

SRV records are cool but fwiw the Roku client is supposed to be doing this: https://github.com/jellyfin/jellyfin-roku/blob/5dbbc98c0fbfd2fd79c8eb9772ed507747b3dc5f/source/utils/misc.brs#L169 If it is not working please file a bug report against the Roku app.

I did, that's where this issue was originally created. Someone else moved the issue to here.

[sevenrats]

It looks like I've followed up there accidentally anyway. I may have kinda duplicated your feature request, but lets move the Roku component of this chat back to here: https://github.com/jellyfin/jellyfin-roku/issues/366 and then this meta issue can remain about SRV records.