Stringray: Could not find your jellyfin server

[Serubin]

I have searched the existing issues to make sure this is not a duplicate report.

• Yes

About the Bug

When signing in to my local Jellyfin, Stingray consistently says it cannot reach the Jellyfin server. The setup is as follows:

Jellyfin is accessible on my local network via two addresses: both https://mylocal.domain/jellyfin and watch.mylocal.domain. I've tried including the protocol https:// as a prefix to the URI and the URI on it's own. In both cases, Stringray cannot connect. DNS is set up locally and in Cloudflare, pointing to the local ip address. In addition, it has a valid certificate setup.

I can connect with SwiftFin from my Apple TV and from other devices on my network without issue.

I did not see any debug logs from my Apple TV that showed what URL Stingray was reaching out to. I also did not get any connection requests to traefik reverse proxy nor to jellyfin itself.

Reproduction steps

1. Open Stingray and attempt sign in

Stingray version

1.0.0

Version of the Jellyfin server you're using. This can be found at the top of the Jellyfin dashboard.

10.11.6

Additional information

No response

[benjaminRoberts01375]

Do you have Jellyfin on a path? Like https://website.com/jellyfin? I haven't tested Stingray against that, but I'm surprised that watch.website.com didn't work.

[msabbott]

I too have this issue.

My Jellfyfin instance is only available on my local network, but can be reached from global DNS using a domain name similar to "jellyfin.subdomain.mydomain.com" (which resolves to a local IP)

I am using http to connect (port 80) and not https.

Traffic is sent to Traefik on my K8S cluster which is routed to the correct application instance based on the hostname. Jellyfin is not hosted on a path (i.e. not http://jellyfin.subdomain.mydomain.com/jellyfin)

When signing in I get the same "Could not find your jellyfin server" message. I have tried adding "http://" to the beginning on the domain name but this did not work either. The port, username and password are set correctly.

The Swiftfin app can correctly access the server from the same AppleTV.

I am using Stingray v1.0.0 and my Jellyfin server is 10.10.7

Thanks,
Mark

[Serubin]

@benjaminRoberts01375 I have jellyfin running on both a path https://website.me/jellyfin and on a subdomain https://watch.website.me/. In both instances, Stingray cannot connect, and there are no logs in Traefik or Jellyfin indicating that Stingray even tried to connect.

Any guidance on how to debug?

[msabbott]

I believe I may have found a possible cause.

I have set up a local HTTP server running on my laptop and directed Stingray to use that as the server. I configured the server to dump the HTTP request headers to the console. This is the output:

Content-Type: application/json
User-Agent: Stingray/2 CFNetwork/3860.300.31 Darwin/25.2.0
Connection: keep-alive
Accept: */*
Accept-Language: en-GB,en;q=0.9
Content-Length: 34
Accept-Encoding: gzip, deflate
Authorization: MediaBrowser Client="Stingray", Device="Apple TV", DeviceId="4F986068-FC78-4E40-B402-7373A12318F6", Version="1.0.1"

Note that what is missing from this list is the "Host" header MDN Link

(Note: There is a chance that this is being sent but not being logged by the simple server that I wrote.)

The Host header is required for HTTP/1.1 connections and is important as it allows a web server to distinguish the correct resource to return to the client whenever that server is hosting data for more than one website (i.e. One server on one IP address is a content hosting platform serving 1000s of websites. Without the header it doesn't know which "/index.html" to return.)

This is the same issue with reverse proxies and with tools such as Traefik - it will be directing the request to the correct container based on the contents of the "Host" header.

If my server did correctly log the full set of headers then this would likely explain the problem that we have been experiencing. Considering we are both using Traefik, it would seem to be a good fit.

To me the resolution is to fix the HTTP client and ensure that the "Host" header is always sent regardless of the HTTP version that is used.

[benjaminRoberts01375]

I'm glad @msabbott found a possible resolution. @Serubin, definitely don't add https:// or http:// since Stingray will do that for you. Ideally, just toggle https on, and set your url watch.website.me. I'll see about adding more descriptive error messages that could help us laser in on the issue. In the meantime, I'm guessing you're not adding a custom port, or anything like that, right? It should pretty much just be:

1. Select HTTPS.
2. Enter your url watch.website.me without any colons or path to a particular endpoint.
3. Enter your login credentials.

I've only tested Stingray against using a subdomain like watch.website.me, not watch.website.me/jellyfin or watch.website.me:9765.

[msabbott]

I've done some further debugging - and it looks like I was probably incorrect. The "Host" header is being sent - but I have found the real cause and a possible solution.

Having managed to update my XCode version, cloned the repo and tested the app in the simulator, I've found that the HTTP requests are being rejected with the exception "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection".

Looking through the documentation for App Transport Security, it will explicitly block HTTP connections (but will allow HTTPS connections.) It can be overridden by specifying the "Allows Arbitrary Loads" property to "YES" in the Info.plist file. Developer Documentation

Note that setting this to "YES" requires a justification in the App Store submission process.

I have been able to test this out in the simulator (without any other changes) and it has worked in my case.

[Serubin]

@benjaminRoberts01375 I get the same error when I use watch.website.me.

I can load this up in Xcode and attempt to debug as well

[benjaminRoberts01375]

Interesting, I remember having the issue trigger an error early in development but only periodically, and I haven't seen it crop up again in over a month. If either of you find that it fixes the issue, feel free to open a PR, or lmk and I'll make the change myself.

[matthewpipes]

In addition, it has a valid certificate setup.

@Serubin I suspect your certificate or server don't meet the requirements or, although unlikely, you root cert authority is not trusted by apple

[msabbott]

@matthewpipes As I mentioned in my first comment, I'm accessing Jellyfin over HTTP and not HTTPS - so certificates cannot be the problem in my case.

[matthewpipes]

@matthewpipes As I mentioned in my first comment, I'm accessing Jellyfin over HTTP and not HTTPS - so certificates cannot be the problem in my case.

My bad sorry, I meant to tag Serubin