[BUG] Jellyfin just doesn't detect Chomecast in network

[the4anoni]

Server System (please complete the following information):

• OS: Raspberry Pi OS ArmHF, Jellyfin Linuxserver docker container
• Jellyfin Version: 10.7.7
• Hardware settings & device: Raspberry Pi 4 4GB ram with OpenMAX
• Reverse proxy: no

Client System (please complete the following information):

• Device: [Chromecast 2]
• OS: [Firmware 275994]
• Client: Android App and Browser
• Browser (if Web client): Vivaldi
• Client and Browser Version: Vivaldi 4.3.2439.65, Jellyfin Android app 2.4.0

Hi
Like in topic - I tried casting from both Vivaldi and android app, no one detects my chromecast. Last time I checked it worked well. Other apps like netflix, youtube, google home, anything other I tried detects chromecast without any problem.
Jellyfin detects other devices like Samsung TV with DLNA or other devices which can be used as jellyfin player, but it doesn't detect chromecast :(

[the4anoni]

I cleared app cache, restarted Chromecast and it works now, lol. I try casting via vivaldi tomorrow.

[the4anoni]

I tested this bit more, looks like when I am logged in to Jellyfin on Vivaldi both phone and PC can't detect Cast for some reason. When I close tab with Jellyfin in Vivaldi and restart app on phone appdetects cast without any problem.

If you need logs tell me which ones.

[the4anoni]

Could this issue be related? jellyfin/jellyfin-docs#588

I don't know

[kristoffern]

Confirmed, I just went through my open Chrome tabs on the Linux server, and sure enough there were 2 open tabs with Jellyfin.
As soon as I closed them down I could immediatelly cast from the Android app again.

[sbranden]

Could this issue be related? jellyfin/jellyfin-docs#588

I don't know

Actually, not related as you are not using a reverse proxy.

[blacklight]

Hey folks, I can confirm the bug.

I have four Chromecasts in my network. All of them are recognized by other apps (including Netflix, YouTube, Plex and others), none of them is even displayed in Jellyfin.

I have tried in Firefox. I have tried in Chromium. I have tried in Vivaldi, Brave and a bunch of other exotic browsers. I have tried from the Android app, as well as from the mobile browser. I have tried accessing the Jellyfin server both over DNS name and IP. I have tried without a reverse proxy and with an nginx reverse proxy with a valid SSL certificate. Nothing works. And we aren't the only ones complaining about this behaviour (evidence 1, evidence 2). So it's definitely an issue on Jellyfin's side. At least the logic that discovers Chromecasts on the network should be a no-brainer (there's tons of libraries that offer that feature, and it's a simple Avahi/mDNS broadcast), so if Chromecasts don't even appear in the view then something is very broken.

Could anybody please take a look? Chromecast support has been broken for months and no solutions nor workarounds have been proposed. I moved from Plex to Jellyfin because I thought that developer/user support was better here. But if nobody even bothers to investigate why such a basic feature like Chromecast support has been broken for months, I won't bother sticking around either.

[cvium]

@blacklight Chromecast is only supported by Android and Chrome (not Chromium). It's proprietary tech... and it has nothing to do with the server.

[blacklight]

@blacklight Chromecast is only supported by Android and Chrome (not Chromium). It's proprietary tech...

How about the Jellyfin Android app? All the video apps I use have native CC support, but Jellyfin won't show anything.

The only way I've managed to get things to (almost) work is by using Google Chrome on my Android phone. Is this the intended use case? Then it should be documented please (e.g. "Chromecast only works on Google Chrome on Android phones"), so tens/hundreds of users won't try to debug something that isn't supposed to work in the first place.

it has nothing to do with the server.

I'm also the developer of a local media server, and I've easily managed to bypass the Chromecast client-side issues by doing a server-side discovery. Now no matter how I access my media content, I can always send it to a Chromecast, because the CC and my server are on the same network, so the CC can easily be discovered over Avahi/Bonjour/mDNS. Then it can be the server itself to provide the client with a list of discovered players, not necessarily the other way around.

The fact that there's no server-side logic to manage the Chromecasts, and instead we rely on the client to discover them, explains why things are so broken. Why not provide a server-side CC scan logic as a backup for users who don't use Chrome on Android but run the server on the same network as the CC, instead of relying on such a brittle client-side implementation?

I can work on a PR for it if enough users are interested in it.

[blacklight]

Update: after getting the app from the Play Store (instead of F-Droid) things work. I hadn't considered that the F-Droid APK was missing the CC libs because of the no-non-free clause (maybe worth mentioning in the FAQ?)

I can also confirm that the devices are detected on Chrome on Android (not on Linux, though). This confirms my suspicion that CC detection is completely managed on the client-side, therefore it can be broken by all the possible limitations of the clients when it comes to the CC protocol. One more point in support of an (optional) feature for server-side devices scan?

[sbranden]

Hi Fabio, Just an observation: server side sounds like it will solve some problems. But what about if server is not on the same network but accessed via reverse proxy. Sounds like client side chromecast support would still be needed in that case?

…

On Thu, Feb 17, 2022 at 6:36 AM Fabio Manganiello ***@***.***> wrote: Update: after getting the app from the Play Store (instead of F-Droid) things work. I hadn't considered that the F-Droid APK was missing the CC libs because of the no-non-free clause (maybe worth mentioning in the FAQ?) I can also confirm that the devices are detected on Chrome on Android (not on Linux, though). This confirms my suspicion that CC detection is completely managed on the client-side, therefore it can be broken by all the possible limitations of the clients when it comes to the CC protocol. One more point in support of an (optional) feature for server-side devices scan? — Reply to this email directly, view it on GitHub <#6840 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSKXNUDR5C4P4ZFZF5Z7OLU3UBXZANCNFSM5H64SYQQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[blacklight]

But what about if server is not on the same network

That's indeed a limitation (Avahi/mDNS discovery only works on local networks), but at least it would solve the problem for those who run the Jellyfin instance in the home network.

accessed via reverse proxy

This shouldn't be an issue, right? I mean, even if the server is accessed over reverse proxy but it's in the home network, the discovery logic will still run locally, so the devices should be discovered.

I acknowledge that server-side discovery isn't perfect and it only works if the Chromecast and the server are on the same network, but at least it would solve the problem to many who aren't running/don't want to run Google Chrome just to have cast support.

[kristoffern]

@blacklight Given that you've worked as a developer with a local media server an CC support previously (ie more CC experience than most people 😅), would you say it's an either or situation?

Ie would one have to choose either client-side discovery or server-side discovery, or is it possible to use them in a fallback fashion? Ie if the server-side discovery fails, then fall back to using client-side discovery, or the other way around.

[blacklight]

Ie would one have to choose either client-side discovery or server-side discovery, or is it possible to use them in a fallback fashion? Ie if the server-side discovery fails, then fall back to using client-side discovery, or the other way around.

In the case of Platypush I tried to keep things as client-agnostic as possible. The server has all the plugins to detect anything published over mDNS/Zeroconf, and it sends websocket updates to the web clients when a new device pops up. And the server also acts as a proxy for all the client control requests to the device.

IMHO server-side discovery could be the default (if the CC configuration/plugin is enabled on the server) if the client doesn't have CC support (and I guess that there can be an easy way to detect it on the client), so cast capabilities can be consistent across all the devices on the same network regardless of the client. Btw, do the Kodi and DLNA discovery processes currently happen on the client or the server?

If instead one wants to leverage the client-side discovery capabilities, then I like the idea of merging server-side and client-side results. After all, any discovery process that occurs over mDNS (or Avahi/Bonjour/Zeroconf/...) can't really fail. It's over UDP, so you would just run the listener (either on the client or the server) for a certain time and return all the devices discovered in that time. Asynchronous device updates over websocket and smart caching can also make the experience smoother, and within something like 30 seconds one would get all the devices on the client - regardless if they were discovered by the client or by the server.

[jellyfin-bot]

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 master branch, 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.

[jellyfin-bot]

This issue was closed due to inactivity.