Chromecast keeps disconnecting
- Thread starter seth_success
- Start date
Burnside
Major Contributor
Thanks. On the CA Evo 150 it is also Cast 2.0:
Google Cast:
1.68.cast_20230721_0201_RC09.549871846I've had problems with VLC and Plexamp through Chromecast and intermittendly with Chrome browser casting (fine with Youtube, fails with Plex), but not with BBC Sounds, so it seems like its some combination of the implementation in the mobile / web app and on the Wiim Ultra that's failing.
For info - as a workaround for Plexamp, you can make your Plex server DLNA enabled (Settings, DLNA, check the "Enable the DLNA Server" box), and then access your Plex library through the Home Music Share option in the Wiim App. Interface is clunky, but works and has no streaming issues (for me at least)
I have periodic transient disconnection of Chromecast from my Ultra while streaming Qobuz, both directly from the Qobuz Android app and through Roon. The amount of playtime before each disconnection varies greatly.
When Ultra drops the Roon Chromecast connection, the endpoint icon will briefly disappear with the message "Select an audio zone". Then Ultra will reconnect with playback paused. Less often in the middle of a track playback will skip to the next track.
I haven't been able to catch what happens with the Qobuz Android app, but I assume it's a similar transient disconnection sequence.
WiiM Support advised me to use Ultra as a Roon Ready endpoint until the problem is fixed. I'm OK with that if there's high confidence that a fix will be relesased soon, but that's totally unsatisfactory if this drags on much longer. WiiM needs to communicate regularly and openly on this forum about how the issue is being addressed.
My fear is that the fix must come from Google and it's most likely a very low priority if the issue is specific to Ultra. Or worse, in the end no fix is possible.
WiiM continues to sell Ultra as a Chromecast device. We deserve more than being told it's a Google SDK issue, please wait...
When Ultra drops the Roon Chromecast connection, the endpoint icon will briefly disappear with the message "Select an audio zone". Then Ultra will reconnect with playback paused. Less often in the middle of a track playback will skip to the next track.
I haven't been able to catch what happens with the Qobuz Android app, but I assume it's a similar transient disconnection sequence.
WiiM Support advised me to use Ultra as a Roon Ready endpoint until the problem is fixed. I'm OK with that if there's high confidence that a fix will be relesased soon, but that's totally unsatisfactory if this drags on much longer. WiiM needs to communicate regularly and openly on this forum about how the issue is being addressed.
My fear is that the fix must come from Google and it's most likely a very low priority if the issue is specific to Ultra. Or worse, in the end no fix is possible.
WiiM continues to sell Ultra as a Chromecast device. We deserve more than being told it's a Google SDK issue, please wait...
Last edited:
mrgene
Member
You are correct that it's not up to WiiM to fix these issues, but it's not really a Google problem.
The Chromecast SDK by Google used to be more or less a chromium browser. When you cast music to a Chromecast device, what is does is essentially opening a web page, like how you would use Spotify web player in a browser. This "web page/web player" is implemented and maintained by the streaming media service provider, not Google. Google is only responsible for the "browser" part.
If you use Chrome, you likely know how bulky and resource intensive it can get. So Google eventually made the decision to re-implement their SDK without dependencies on the Chromium engine. It should have been a nice thing, but unfortunately the streaming media service provider has gotten used to doing whatever they want over the last few years. They can use whatever APIs they want, as Chromium engine has great support for the majority of Web APIs.
That's not the case with the updated Chromecast SDK. There is a list of supported APIs on
Audio Devices | Cast | Google for Developers
Learn how to cast with audio-only devices: device capabilities, memory usage guidelines, volume control, and more.
developers.google.com
So, in case of casting problems from Mixcloud to Ultra via Chromecast, problem should be fixed on Mixcloud side?You are correct that it's not up to WiiM to fix these issues, but it's not really a Google problem.
The Chromecast SDK by Google used to be more or less a chromium browser. When you cast music to a Chromecast device, what is does is essentially opening a web page, like how you would use Spotify web player in a browser. This "web page/web player" is implemented and maintained by the streaming media service provider, not Google. Google is only responsible for the "browser" part.
If you use Chrome, you likely know how bulky and resource intensive it can get. So Google eventually made the decision to re-implement their SDK without dependencies on the Chromium engine. It should have been a nice thing, but unfortunately the streaming media service provider has gotten used to doing whatever they want over the last few years. They can use whatever APIs they want, as Chromium engine has great support for the majority of Web APIs.
That's not the case with the updated Chromecast SDK. There is a list of supported APIs on
, and if the web player uses unsupported APIs, it will not play correctly. It's up to the streaming media service provider to update their web player code to work on the new Chromecast SDK.Audio Devices | Cast | Google for Developers
Learn how to cast with audio-only devices: device capabilities, memory usage guidelines, volume control, and more.
Burnside
Major Contributor
So what are you saying? WiiM should be pushing Qobuz, BubbleUpnP, BBC Sounds etc etc to fix Chromecast issues with the Ultra? I don’t get that at all…You are correct that it's not up to WiiM to fix these issues, but it's not really a Google problem.
The Chromecast SDK by Google used to be more or less a chromium browser. When you cast music to a Chromecast device, what is does is essentially opening a web page, like how you would use Spotify web player in a browser. This "web page/web player" is implemented and maintained by the streaming media service provider, not Google. Google is only responsible for the "browser" part.
If you use Chrome, you likely know how bulky and resource intensive it can get. So Google eventually made the decision to re-implement their SDK without dependencies on the Chromium engine. It should have been a nice thing, but unfortunately the streaming media service provider has gotten used to doing whatever they want over the last few years. They can use whatever APIs they want, as Chromium engine has great support for the majority of Web APIs.
That's not the case with the updated Chromecast SDK. There is a list of supported APIs on
, and if the web player uses unsupported APIs, it will not play correctly. It's up to the streaming media service provider to update their web player code to work on the new Chromecast SDK.Audio Devices | Cast | Google for Developers
Learn how to cast with audio-only devices: device capabilities, memory usage guidelines, volume control, and more.
mrgene
Member
Yes. For this particular case on Mixcloud, it’s completely up to Mixcloud to fix the issue. I can’t share the details, but let’s just say that it’s still possible to cause memory leak in JavaScript if not careful.
mrgene
Member
WiiM doesn’t have a working relationship with them though. But Google does, so it’s up to Google to push the service providers to fix their code. But for small developers like Bubblesoft, they don’t have regular contact with Google. It’s probably more efficient if we, the users, submit logs and feedback to BubbleSoft directly. That’s what I did anyway.
What WiiM devices run is formerly known as Chromecast built-in. It’s just a run-time for running web players. Think of it like your browser. You use your browser to open web pages.
Then there are web receivers, written in HTML and JavaScript by the streaming media service providers. They are like YouTube and Netflix. Say you use your browser to watch videos on YouTube, it’s not always the browser’s issue when the video doesn’t play well, is it?
Let me stay with the browser analogy, back in the days when Chrome was still fresh to the market, lots of the websites weren’t optimized for Chrome. They did not show correctly on Chrome, but they were fine in Internet Explorer. Eventually, websites adapted to Chrome, and not the other way around.
This is the same situation Google Cast is dealing with now. If you check the Google developers page I posted earlier, developers are now advised to test their receiver apps on GC4A 2.0 devices, as all existing devices will migrate to GC4A 2.0. I expect a lot of growing pain. But as more devices are being mandated to upgrade to GC4A 2.0, I also expect more media service providers to prioritize fixing these issues.
Burnside
Major Contributor
Have you had any response from BubbleSoft or other providers?
mrgene
Member
I got a very generic reply that they tested okay on their chromecast devices and will look into the issues. I followed up with an explanation on the difference between chromecast and GC4A 2.0, and the fact that I can observe issues in all GC4A 2.0 devices: WiiM Ultra, JBL speakers, Bose soundbar. I’m not sure how serious they take my emails though because there aren’t many GC4A 2.0 devices currently out there.
As for other providers, I can’t discuss the details. But most of them either don’t know about GC4A 2.0, or don’t consider the issue urgent (given that most chromecast devices are still running 1.56). Those who understand the difference are using the term “Google Cast” as opposed to “chromecast”, which was dropped since Late 2023. (But only made public this fall.)
'Google Cast' is replacing the 'Chromecast built-in' brand
At I/O 2024, "Chromecast built-in" was quietly rebranded to "Google Cast." Notably, this is reversing a branding change made in 2016...
9to5google.com
I think it's (mostly) safe to say that lazy website producers finally adapted existing HTML, CSS and JavaScript standards, not the broken parodies implemented by Internet Explorer.
It was a painful period.
Thanks for explaining all this in such a detailed manner. I found it pretty hard to find any meaningful resources from Google just searching for "Google Cast" or "Chromecast Lite" or "Google Cast 2.0". Obviously it's much easier if you already know the term "GC4A 2.0".
This sheds quite some light on what's happening (also with other vendors). In particular there is this section ...
... that not everyone will like reading about.
That will stop the use of Google Cast Groups as a simple way to get high-res, multi-room streaming with products from various manufacturers. It only takes one Google Cast 2.0 device to limit the group to CD quality.In particular there is this section ...
... that not everyone will like reading about.
mrgene
Member
HTMLMediaElement is one set of the APIs supported by the new Google Cast SDK. For Hi-Res, the media service providers can choose to implement their web receiver with Media Source Extension, which is mentioned just slightly above the line you quoted.I think it's (mostly) safe to say that lazy website producers finally adapted existing HTML, CSS and JavaScript standards, not the broken parodies implemented by Internet Explorer.
It was a painful period.
Thanks for explaining all this in such a detailed manner. I found it pretty hard to find any meaningful resources from Google just searching for "Google Cast" or "Chromecast Lite" or "Google Cast 2.0". Obviously it's much easier if you already know the term "GC4A 2.0".
This sheds quite some light on what's happening (also with other vendors). In particular there is this section ...
... that not everyone will like reading about.
2MB of buffer may seem like nothing, but 1 second of uncompressed 32-bit 192hz WAV audio data uses about 1.5MB. If it’s the more realistic 24-bit 96hz data, the number is closer to 0.6MB. If the audio source is FLAC, it’s even less than that. As long as the web receiver gets the data more frequently in small batches, it’s perfectly fine.
This is the precise reason why Roon is problematic over GC4A 2.0. It goes against the guideline and uses much more buffer than that in order to achieve better audio casting quality. The more buffer you have, the less you are affected by network issues. It’s also why Plex doesn’t work, because plex expects to send the entire song to the buffer at once.
Burnside
Major Contributor
@adias hi, you seem to have regular contact with Ethan in WiiM Support over Chromecast issues on the Ultra - do you want to bring this and related comments to his notice and see if it elicits any insightful feedback? Thanks
Post in thread 'Chromecast keeps disconnecting'
https://forum.wiimhome.com/threads/chromecast-keeps-disconnecting.4368/post-78625
Post in thread 'Chromecast keeps disconnecting'
https://forum.wiimhome.com/threads/chromecast-keeps-disconnecting.4368/post-78625
I am sure @WiiM Team and @WiiM Support are aware of these issues. In my interactions they indicated that the service providers had to be involved; I did not understand that but now we all do, given what we learned from the excellent posts by @mrgene.
So this will be a long process.
