Chromecast not working

[brianjmurrell]

Describe the bug
Trying to play to Chromecast from Android results in nothing actually happening.

To Reproduce

1. Click Chromecast icon, choose a Chromecast to cast to
2. Click on media file

Expected behaviour
Should play the media to the Chromecast. It doesn't. The mobile app screen doesn't change when play icon is pressed other than a translucent blue circle drawn around the play icon.

Logs
There are none. There is nothing added to the log when the media item's play icon is pressed.

System (please complete the following information):

• OS: Android 8.0
• Browser: Chrome
• Jellyfin Version: 10.3.3
• Reverse proxy: no

[brianjmurrell]

On Chrome on Linux, the Chromecast button doesn't even see my Chromecasts. I am able to cast any arbitrary tab in Chrome and Netflix in the same Chrome is able to see my Chromecasts, so this seems to be another bug of the Jellyfin Chromecast.

[anthonylavado]

@brianjmurrell Chrome on a desktop will not allow a page to cast unless it is secured (HTTPS/SSL). Netflix does have SSL, so that works. Tab casting also works, because it’s not the website, but the application.

Do you have HTTPS set up for Jellyfin?

[anthonylavado]

I should note - the App should work whether or not you have HTTPS, I’m just trying to determine if there is an actual web/server error, or if this issue belongs with the Android app.

[brianjmurrell]

@brianjmurrell Chrome on a desktop will not allow a page to cast unless it is secured (HTTPS/SSL).

Ooops. Yes. I was not on the HTTPS port. Using the HTTPS port from my Linux/Chrome I see the same "nothing happens when you try to play to Chromecast" behaviour. It's as if I just didn't even click the Play icon.

[brianjmurrell]

To be clear, I am not using any dedicated Android app but just using the web-app in a Chrome tab. TBH, I don't really see the point of a dedicated app when the web-app works just as well and (almost?) identically to a dedicated app.

[anthonylavado]

TBH, I don't really see the point of a dedicated app when the web-app works just as well and (almost?) identically to a dedicated app.

There is working going on now to add better video players to the Android app, so soon it will be able to handle more formats than just the web app alone can. More format support means less transcoding, means easier experience :-)

...Using the HTTPS port from my Linux/Chrome I see the same "nothing happens when you try to play to Chromecast" behaviour. It's as if I just didn't even click the Play icon.

Try having the DevTools open during this, and see if there are any errors that appear in the console. That should give us a start to help track it down :-)

[brianjmurrell]

Nothing new appears in either the Network tab nor the Console tab when I press Play. If I don't have Chromecast enabled, it plays in the browser fine.

[anthonylavado]

Hrm... Try this in order:

• Open new Tab
• Open DevTools to Console. Make sure the log levels are set to "Default levels"
• Load Jellyfin home page, login as needed

You should see the following messages after everything loads up on screen:

[bensweet86]

I've been playing around with this too - same issue with http/https initially. I run a reverse proxy for https and if the ssl certificate was missing / invalid the web ui would connect to the chromecast but refused to cast with random or no messages. As soon as there was a valid SSL certificate casting worked fine.

[brianjmurrell]

@anthonylavado So, doing as you requested, I do see the lines you refer to. I then go on to play a media file and this is added to the messages:

But nothing correspondingly is added to the jellyfin log to indicate that it's gotten the request or is fulfilling it.

[anthonylavado]

Okay, so the other lines are mainly when the user clicks away, and then back on the web app, so those are normal.

So it’s definitely seeing the Chromecast is available...

I don’t think we covered this earlier, but does the Chromecast show the Jellyfin “Ready to cast” page when you connect to it?

[brianjmurrell]

does the Chromecast show the Jellyfin “Ready to cast” page when you connect to it?

Yes, and a clock on the top right at some point, while on the Jellyfin "Ready to cast" page.

[maxaudron]

im seing the same happening for me. Both webapp and android app connect to the chromecast and it shows the jellyfin page but im then not able to play anything.
the jellyfin server is secured by https.

[anthonylavado]

Sorry folks, I have no idea where to proceed further from here. Paging @jellyfin/support for any ideas.

[maxaudron]

For me it was not automaticly detecting the correct WAN IP by itself as it is behind a reverse proxy. After setting them myself in the advanced settings it now works.

[sparky8251]

Does the solution maxaudron found work for you @brianjmurrell ? This is a bizarre issue and one we are having trouble finding solid info on.

[brianjmurrell]

My Jellyfin is not behind a reverse proxy and I am accessing it from the local network it's on. Is the WAN address even relevant here?

In the dashboard it has http://my_domain:8096 for the WAN address. my_domain does not resolve to an IP address.

[sparky8251]

It's possible that could be breaking it. Incorrect WAN detection broke the Kodi addon before. It shouldn't care about the WAN IP but it did...

Make sure its resolvable, even if only internally (like set it to a local IP address) and see if it helps. If it is WAN detection, that means we have 2 clients we need to fix to rip that section out of the web ui like we've been meaning to.

[brianjmurrell]

Where is it getting that value (of the WAN address) from? Why is it using my domain and the LAN address is using an IP address?

What if I don't want to have my domain resolve to an IP address to force clients to use host+domain name nomenclature?

[sparky8251]

As far as I know, there should never be a domain name in that field. I didn't even know it was possible.

It gets the value in that field from ipv4.icanhazip.com, and that should only return IPs. That said, I think maxaudron found some way to set it manually based on his comments here. Worst case, you might be able to set it by hand in one of the xml files JF uses to store conf data. Just try to avoid loading pages in the web UI, I think every page loaded writes a new value to that file... You can check by curling the /emby/system/info/public API I believe. That returns the current set value.

Frankly, this is just troubleshooting/working around an issue for now. the end result should be a proper client that doesn't need to know what the WAN address is, IP, domain, or other. Just want to see if we can track down the cause of your suffering specifically, then we can work on fixing it right.

[flatline-studios]

I'm facing this exact issue.

Using the Android app, just a blue highlight colour on the button, and nothing else happens.

I'm not using SSL on the server or a reverse-proxy, and am just using the linuxserver.io docker image.

My actual, internal IP address (shown with ip a) is 192.168.0.34.

Jellyfin shows:
My LAN address is 172.19.x.x : 8096 - Which is the docker containers IP address I believe.
My WAN address is < SNIP > : 8096 - Which is correct (but I'm not sharing my server with the internet, it's only local)

Looking at the logs, when I push the play button after connecting to my Chromecast, it says:

`[2019-06-27 17:39:18.403 +01:00] [INF] Profile: "Unknown Profile", Path: "/data/tvshows/< SNIP >.mkv", isEligibleForDirectPlay: True, isEligibleForDirectStream: True

And nothing else... Not sure if it's relevant or not... Just seemed weird it say's Unknown Profile.

[maxaudron]

you can set the wan ip in the advanced settings page.

[brianjmurrell]

@maxaudron Where? I don't see anywhere on the Advanced page to set the WAN IP.

[gaelalso]

@gaelalso what's the output of dig <domain name> @8.8.8.8 from within the network that it isn't working in, and using the domain name that wasn't working for you

Can you tell me how to do this test. Sorry I'm a beginner

[JonnyHaystack]

@gaelalso Just run that command on a Linux machine. The command is in the bind-tools package (on Arch at least) so make sure that's installed.

[TobiasB91]

I'm running the linuxserver docker image in combination with the letsencrypt + nginx and I do have the same issues. Local casts work fine, but if I connect over nginx chromecast just does not start.

[lu4p]

For me setting "secure connection mode" in "networking" to "handled by reverse proxy" fixed my casting not working at all.

I use caddy as a reverse proxy.

[huuub]

dig @8.8.8.8 works for my domain from everywhere.
I use traefik2 and docker container for jellyfin.
I have a valid letsencrypt certificate.
Blocking google DNS is still the only option? That is not really a solution :(

[mazzystr]

Chromecast Ultra / Chromecast protocol works for me and I probably have the funkiest set up in the community, Lol!
DNS external: domain.com / afraid.net / mydomain.co -> 1.2.3.4 (Server)
SSL: Let's Encrypt cert for mydomain.co
Network & Firewall: Linksys Nighthawk r7800 / OpenWRT
DNS internal: dnsmasq (on OpenWRT) / mydomain.co -> 192.168.0.10 (Server)
Server: Core i7-4770k / 16 gig mem, CephFS (36 tb)
App: HAproxy (containerized) -> Jellyfin 10.5.0 (containerized with host networking because dlna). Jellyfin configured with Secure Mode: disabled and BaseUrl: /jellyfin

[bengalih]

I too have no issues with Chromecast working without blocking 8.8.8.8.
I host NGINX on my Asus-Merlin router which serves DNS internally and is configured to use Cloudflare's DNS (1.1.1.1, 1.0.0.1) externally.

All internal hosts are pointed to the router for resolution, however I redirect all external domain (mydomain.com) to resolve to the router itself. For example in my dnsmasq I have:

server=/mydomain.local/10.10.10.100
server=/10.10.10.in-addr.arpa/10.10.10.100
address=/mydomain.com/10.10.10.1

This causes all requests to my internal .local domain to be forwarded to my internal AD DNS (10.10.10.100) so domain communications function properly. And all requests to my external domain go straight to the NGINX server on the router (internally). It does however work without this second redirection, but I believe this has better tolerance against internet down issues, as well as allows all requests to be local. If your router has issues with loopback this might also help.

Other relevant info may be that I use a subdomain not folder (i.e. jellyfin.mydomain.com) and LE certs. My external DNS is hosted by Cloudflare, but that is mostly irrelevant - however this works with CF proxy enabled or not.

My JF configuration is pretty standard however - simply running as a service on a Windows server with no additional abstraction of internal networking. Secure mode is "handled by reverse proxy" and does not work properly if configured otherwise.

Note my only Chromecasting happens to a Mini/Nest device (i.e. audio only) but it works fine internally as well as if I am casting to a Mini device located outside my network.

It is well known that google devices are hardcoded to 8.8.8.8 unless they are blocked. However I don't believe blocking it is the only solution for your issues as I believe there are many not blocking this that have functionality. My guess is something strange is configured with your external DNS. There is no reason that what google can resolve for you external DNS should be different than what the authoritative name server...or any other name server should provide. If you are depending on an internal DNS server to provide split-DNS then blocking an external DNS shouldn't be a big deal. After all, if you don't want Google's DNS to provide the info, then why worry about blocking it?
You should be able to selectively restrict your Chromecast devices using firewall rules.

[TobiasB91]

As it turns out my issue isn't DNS but rather hardware transcoding ( #1882 ).

[huuub]

Do I need to have an internal DNS server for that? I still don't understand the issue we are having? Could it be that the link that the link that is used by chromecast is not received by traefik and forwarded?

[tsdragon]

I'm still having this problem.

Using the jellyfin/jellyfin docker image, version 10.5.5, installed on Ubuntu server 18

• Playing on Android and Web devices works fine.
• I am using Traefik as a reverse proxy server.
• ALL DNS queries including those to 8.8.8.8 and 8.8.4.4 are re-routed to my local DNS server
• Local DNS server has the Traefik server LOCAL IP added for the jellyfin server domain (as well as many others)
• Traefik server is correctly giving out LE certificates that show as valid in Firefox and Chrome.
• Domain is a subdomain, so jellyfin.mydomain.com
• Uses https over 443 via traefik
• http over port 80 redirects to https over port 443 via traefik

To try to fix this I have tried:

• Public ports set to 80 and 443
• Secure connection mode set to handled by reverse proxy
• even changed local https port to 443
• added correct LAN network range

Each change was made one by one, restarting the JF server every time and closing all apps just to be sure. No changes in behaviour were observed whatsoever.

JF logs show absoluely nothing when clicking play on any title while connected to the cromecast, either from Adroid of Chrome browser.

Chrome browser verbose console logs show the correct URL being requested by the JS. Console logs also show:
chromecastplayer.js?v=10.5.5:380 Message was sent to receiver ok.

The basic JF logo and "Ready to cast" is continuously displayed on the TV with no change either. Also there are no background images shown, only a black background.

[programmer8922]

* ALL DNS queries including those to 8.8.8.8 and 8.8.4.4 are re-routed to my local DNS server
* Local DNS server has the Traefik server LOCAL IP added for the jellyfin server domain (as well as many others)
* Traefik server is correctly giving out LE certificates that show as valid in Firefox and Chrome.
* Domain is a subdomain, so jellyfin.mydomain.com
* Uses https over 443 via traefik
* http over port 80 redirects to https over port 443 via traefik

@tsdragon, my setup was basically the same as this, and I had the exact same issue. After doing packet capture, I found that the http redirects weren't being honored. To work around this, I changed the android app server setting to "https://jellyfin.mydomain.com" (where I had originally used "jellyfin.mydomain.com").

[tsdragon]

@programmer8922 I just tried you fix and experience no change.

It seems to work if I allow the chromecast to use the remote IP (cloudflare) instead of local but this is unideal

[tsdragon]

I have solved my problem. It seems to be related to how I had the networking done. For some reason redirecting DNS from anything hard-coded (ie, Chromecasts) directly to my Local DNS was what was causing the issue. Redirecting instead back to my router, then letting the router handle forwarding to the DNS server solved my problem. My issue was not related to the Jellyfin software.

[huuub]

Could you explain this a bit more?
For some reason redirecting DNS from anything hard-coded (ie, Chromecasts) directly to my Local DNS was what was causing the issue. -> Not sure what you mean here?

[Zagitta]

In case anyone is looking for a somewhat elegant fix to chromecast's hardcoded DNS with a openwrt/tomatousb/linux router it's possible to setup mac address specific firewall rules that redirect dns to the local one like this:

iptables -t nat -A PREROUTING -m mac --mac-source <chromecast mac> -p udp --dport 53 -j DNAT --to-destination <dns ip>
iptables -t nat -A PREROUTING -m mac --mac-source <chromecast mac> -p tcp --dport 53 -j DNAT --to-destination <dns ip>

I've personally added it to the firewall script section on my tomatousb router.

[brianjmurrell]

@Zagitta Why limit it to Chromecast devices? Should any device in your network be able to subvert your authority over what IP addresse(s) a given name resolves to in the perspective of your own network?

Surely in 99.99% of the cases, it will be what any other external resolver would answer, but why not reserve yourself the right to decide that?

RP zones (for ad and tracker blocking for example) are great use-case for this.

DNS queries can also be the canary in the coal mine to machines in your network that have become infected with viruses, or are botnet zombies. Forcing them to using your own DNS can help you track down that kind of shenanigans.

DNS queries are also a potential privacy leak. Why let some DNS resolver operator know all of the websites you use?

Ultimately, IMHO, if I'm responsible for the network, then I shall be who answers name queries for you, not anyone else.

[bengalih]

Ultimately, IMHO, if I'm responsible for the network, then I shall be who answers name queries for you, not anyone else.

Which is why no device should be allowed outbound 53 at all with the exception of your DNS server.
That is really "best practice" and I believe if configured that way this wouldn't be an issue. Since in that scenario the Chromecast devices wouldn't be able to communicate with their preferred Google servers, they should fall back to what you have assigned as your internal DNS server.

[brianjmurrell]

Which is why no device should be allowed outbound 53 at all with the exception of your DNS server.

Right. Just what I am saying. Sadly, there is DoH and DoT to deal with. :-(

[Zagitta]

@brianjmurrell I was simply offering a tip for people like myself that might not be iptable rule wizzards, I don't care how you or anyone else runs their network :-)
Furthermore there are lots of scenarios where it doesn't make sense to redirect all DNS trafik, for example in my case I run Traefik + letsencrypt with DNS challenge which simply doesn't work with internal dhcpd.

[huuub]

Ok, so this doens't solve the problem when you take your chromecast on another home network. What is jellyfin doing different?

[stale]

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

[huuub]

Well it is not solved...

[mooninite]

Correct. This and issue #3712 are duplicates. See the other issue for a workaround using Apache or nginx filtering/substitution of the JSON data returned from the /system/info/public API endpoint. FYI - Emby fixed this by changing their Chromecast code to no longer use the /system/info/public API endpoint during Chromecast setup so Emby does not have this problem anymore.

[YouKnowBlom]

This is a call for testing for anyone that is available: jellyfin/jellyfin-web#2085