-
-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't control Chromecast media playback (unstable version doesn't function) #351
Comments
Unstable stopped working after enough blind dependency merges about 7-9 months ago. |
Thanks. I guess the last time I came back about this was March, so it has been about 9-10 months maybe since I last visited this issue.
There are a lot of bugs on this (including a couple I opened), and if this is the case, I would be happy that this one is closed down with some information on which bug/feature request I should be tracking that will have the appropriate updates on it. I thought this was close to being fixed 10 months ago, but perhaps there hasn't been much progress. |
The hopes and aspirations of a functional Chromecast receiver more or less hinges on #107 which went into limbo a year ago. |
I'm just updating that this is still an issue on 10.8.4. While I am able to get cast work using the "stable" chromecast client (and pretty much always have, even with my reverse proxy), I am unable to cast at all using the "unstable" client. It allows me to see and connect to devices, but immediately gives a "Your Google Cast receiver is unable to contact the Jellyfin server. Please check the connection and try again." when pressing play. I need to be able to use the "unstable" client, since I have been notified multiple times on this GH that is the only solution to be able to actually pause/resume playback on a chromecast device which currently does not recognize that anything is playing when streaming from JF. I believe this is still awaiting #107 being implemented which appears to have been completed and verified, but seems to have been unmerged for almost 3 months. Is there a way to get an update on that progress? It appears that @YouKnowBlom is the gatekeeper on this and has been unresponsive for months in the past when the issue appears solved and ready to implement. I know everyone has more than this on their plate, but this has been an issue forever and basically makes JF unusable on Chromecast devices for the most common use-cases (users who want to actually be able to stop playback). I would just like an update as to when we might see these fixes implemented and CC media controls working. appreciate all of you! |
Describe the bug
This is an update of #118, which I am closing down now so that we can have updated info.
I am also narrowing the focus of this bug to just playback issues on Chromecast, and not to discuss the Android client issues.
The issue still at hand is that when casting to a Google device (in this case a Mini/Nest), the Cast device is unaware that anything is playing.
To Reproduce
Expected behavior
I would expect at the very least that #3 should properly pause playback.
I should also expect that the cast client is aware of what is playing (if not the specific media, then at least "Jellyfin").
My expected behavior is based on what Plex does - it will actually name the media playing and properly pause/resume.
Logs
System (please complete the following information):
Additional context
In the past, using the "Unstable" version of Chromecast is recommended. However when I try to use the unstable version I get the error:
"Your Google Cast receiver is unable to contact the Jellyfin server. Please check the connection and try again."
I will note that I use an NGINX reverse proxy configuration in a subdomain setup (http://jellyfin.mydomain.com).
I use an LE (not self-signed) cert and always connect to the secure FQDN.
I am using in effect, the same configuration shown here for testing:
https://jellyfin.org/docs/general/networking/nginx.html
My reverse proxy works for streaming to my mobile devices when outside my network, and for all intents and purposes appears to function properly when using the Stable version of CC outside of the main issue presented in this bug.
I suspect that the behavior I experience is correct for the Stable version (?), but I do not know if this should currently be fixed in the Unstable and, if so, why I am no longer able to connect when using it.
The text was updated successfully, but these errors were encountered: