Not able to connect to chromecast on 10.7, works on 10.6

[hawken93]

Describe the bug

Making this on behalf of people that are going to have this problem and already have.

E.g. https://www.reddit.com/r/jellyfin/comments/ko1s7r/jellyfin_1070_release_candidate_2_incoming_now/ghphrf6/

The problem is that the LocalAddress field is not being used anymore since https://github.com/jellyfin/jellyfin-web/pull/2085 which closes a slew of issues for people that are using reverse proxies and other setups where the jellyfin server doesn't know if the chromecast should be using the address, and if the address is correct.

However, this workaround tries to get around:

• https issues
• DNS issues

To Reproduce

The two scenarios that the old behavior tries to fix are DNS and HTTPS scenarios. For a DNS scenario:

1. jellyfin server on server.local (192.168.1.2:8096)
2. jellyfin web on client.local (192.168.1.3) with chrome://flags set to allow casting from http
3. chromecast on ccast.local (192.168.1.4)
4. client opens server at http://server.local:8096. This will show that you can cast to chromecast but you get a connection error.

For https scenario:

1. server.local is now at 192.168.1.2:8443, with snakeoil certificate. Cert installed as CA root so that it seems valid to the server
2. client.local installs the snakeoil as a CA root, making the certificate seem completely valid.
3. chrome opens https://192.168.1.2:8443 and can cast without a workaround since it's "secure".
4. when casting the chromecast refuses to connect and gives a connection error.

For this scenario I state that the cert will be installed as CA root, to show that the client or server will not be able to perform validation to predict if the chromecast will fail. In this case I think http will be closed on jellyfin and a fix is not possible.

For https scenario with snakeoil reverse proxy:

1. server.local is now at 192.168.1.2:8096 with nginx+snakeoil at 443. Cert installed as CA root so that it seems valid to the server
2. client.local installs the snakeoil as a CA root, making the certificate seem completely valid.
3. chrome opens https://192.168.1.2:443 and can cast without a workaround since it's "secure".
4. when casting the chromecast refuses to connect and gives a connection error.

Here the chromecast could have used the 8096 port to connect successfully, as long as this is not blocked.

Localhost scenario:

1. desktop.local at 192.168.1.2:8096
2. chromecast at 192.168.1.3
3. person on desktop.local opens chrome and connects to localhost:8096 and casts from there
4. chromecast tries to connect to itself

In this scenario, the workaround would send the LAN address of the server to the chromecast before.

Expected behavior

According to the old behavior:

1. jellyfin-web judged that the normal address was a DNS name and therefore used LocalAddress instead
2. server judged that the chromecast was on the same LAN, uses LocalAddress which probably is https and fails anyway
3. server judged that the chromecast was on the same LAN and therefore used LocalAddress which made the thing work by going directly to server.

Possible fixes

I want to send two addresses to the chromecast. I want to send it the preferred address and the fallback address. Then the chromecast tries them and preferentially selects the normal one. If it fails, it tries the fallback one.

As for LocalAddress I would ideally make a new API instead and call it FallbackAddress or something. Then it should have a toggle button in the settings and a field so it can be overridden. With this thinking we can deprecate LocalAddress from the API and a bunch of the detection code that is bound to fail because it was the wrong approach to begin with.

We don't know for sure if DNS names warrant using LocalAddress. It may be a valid internet name. We also don't know if HTTPS is an issue. The certificate might be valid.

I think the best here is trial and error.

If jellyfin closes the http port as https is activated, and the certificate is not internet-valid, then there's just no solution.

[ownbee]

So one problem is Chromecast uses the DNS at 8.8.8.8, which cant resolve server.local. I think this is a Chromecast limitation/issue rather than a Jellyfin problem. In my opinion, this is something that shouldn't be part of the default Jellyfin "workflow". But to assist work-around, I see 4 clean solutions:

1. Chromecast asks/gets a resolved domain name from Jellyfin server (it does the NS lookup). I don't know if it's possible to get a bad resolve (e.g. some docker address), it's crucial to use the authoritative DNS answer. This should be an option though since if you are outside your LAN and want to cast to a Chromecast, you might get wrong, unwanted address. For example, mydomain.com resolves to 192.168.1.100 on my LAN (where my local DNS and Jellyfin server is located) but my WAN address by external DNS servers (e.g. by 8.8.8.8).
2. An option in the server to set/override Jellyfin server address used by the Chromecast. Very simple and clear in my opinion.
3. Make a rule in your router to forward all DNS requests from Chromecast to your local DNS (dns.local instead of 8.8.8.8). This is what I've done to eliminate unnecessary WAN traffic. This is very neat work-around for the annoying hardcoded DNS but requires some networking experience by the user.
4. Don't use local domain names and instead, connect to Jellyfin by IP if you want to use Chromecast. But this is not an option if you really want reverse-proxy.

I vote for a non complicated solution and only give 1 address to Chromecast, with the option to override the given address in Jellyfin settings (solution 1 or 2).

[hawken93]

This solution is not non-complicated and it was the one used before, the logic error with this approach is that it's wrong to assume that it's less complicated because the chromecast only gets one address.

Here's the issue: Nobody except for the chromecast device can for certain say if it will work or not. Only the chromecast can. This fact leads to a lot of ugly guesstimations and heuristics from both the server and the chromecast sender device that turn out to cause problems in other situations than the ones they were made for. For instance in the reverse proxy scenario, there's mostly no reliable way for the server to know what IP clients should use to connect to it. That caused problems. In similar situations, the normal endpoint would work fine, but due to networking guesstimations, the server assumes it has to use a workaround when it really doesn't.

It's much easier then to do this:

• guesstimate an alternate address that may be wrong. Make it overridable
  • This is implemented today.
  • set "Published Server URIs" to the external ip:port of the host running the service. Syntax: "external=http://192.168.1.100:8096"
• Send both to chromecast so that it can use the alternate address as a fallback. Then it will be used only when it's needed, and never when it's not needed.

[hawken93]

With android fix on the way and stable fix in, I think we need to wait for them and see after that if people are able to get around these pitfalls or not.

[datosh]

Just ran into this issue that I was not able to cast from my Android app to Chromecast, since the app was configured to use http://jellyfin.home, after reconfiguring app to use IP:port instead casting worked.

[bloodyburger]

I'm using Jellyfin on remote VPS over https and iOS and cast button doesnt show any of my devices.

[MarcelRobitaille]

Not sure if this is related or not, but chromecast is not working for me in a browser or in the android app, but it is working perfectly in Yatse. I am using SSL (let's encrypt) and I redirected 8.8.8.8 to my pfSense DNS. I am also using a registered domain.

[igor-martinovski]

Also not working here with a browser (chrome, firefox) and iOS app. I am also redirecting 8.8.8.8 to my local dns server and have a lets encrypt cert and a reverse proxy. I've tried reaching JF through HTTP, HTTPS, IP and domain name and chromecast does not show up in the player for any of these combinations. I am running JF 10.7.7 in Ubuntu 20 without docker.

[teh-mouses]

This issue still exists.

System: Samsung Galaxy chromebook. Stable channel.

Expected behavior - when I click the cast button, it shows the various Google Chromecast devices in my house and allows me to cast to them.

What happens: Nothing. The cast menu simply shows 'my device.' Works great on my android phone and behavior is good and expected. Something is very wrong here.

[JamesSauter]

Total Noob here... I just installed Jellyfin in hopes of replacing Logitech Media Server for all my Squeezebox devices, as well as all my newer Audio and Video Chromecasts. So far, Casting is working if I use my phone to stream files from my PC to any Chromecast, but If I try to stream direct from a Chrome window on my PC, The Chromecast "dings" as it connects, and I CAN adjust the volume if I am in Remote mode, but it will not cast the audio. As soon as I try to play audio I get this message:

[teh-mouses]

Exact same issue here.

On Sun, Nov 13, 2022 at 3:40 PM JamesSauter @.***> wrote:

Total Noob here... I just installed Jellyfin in hopes of replacing Logitech Media Server for all my Squeezebox devices, as well as all my newer Audio and Video Chromecasts. So far, Casting is working if I use my phone to stream files from my PC to any Chromecast, but If I try to stream direct from a Chrome window on my PC, The Chromecast "dings" as it connects, and I CAN adjust the volume if I am in Remote mode, but it will not cast the audio. As soon as I try to play audio I get this message: [image: image] https://user-images.githubusercontent.com/107403515/201545820-04004ff0-9a2c-4394-a558-e2f56a816bc0.png

— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-chromecast/issues/113#issuecomment-1312829054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKLETLN6WRP4O5UFUKRZWCDWIFN45ANCNFSM4V2HN3TQ . You are receiving this because you commented.Message ID: @.***>