Chromecast Device Issues: Problems Enabling and Playback Stops After a Few Seconds

Support
1

Core Machine (Operating system/System info/Roon build number)

Ubuntu 18.04.5 LTS (x64) / Intel NUC7i7BNH / Server 1.7 (build 667) via Easy Installer

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

WiFi via Google Fiber Network Box (mix of 2.4 and 5GHz clients)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Problematic devices are a Chromecast Audio into an Hegel H120 via optical, 2 Nest Audios (2020), and cast groups associated with these devices.

Description Of Issue

Very new to Roon; currently at the beginning of my trial period, and initial impressions are that I am in love with everything that Roon offers, and I’m entirely frustrated with my experience so far. Initial setup of Roon server was painless via Easy Installer. Configuration of zones/audio devices except for Chromecast devices has been painless. Streaming directly to the Hegel via Airplay works great, streaming to my iPhone and to the desktop app work great, but both enabling and streaming to any of the Chromecast devices or cast groups has been an absolute nightmare. When I’m able to get the devices enabled, playback works for approximately 3-5 seconds and then cuts out… every… single… time.

In any case, here is a sample from the logs when attempting to enable a Chromecast device as a Roon endpoint (Chromecast Audio, v1.42.172094):

10/21 11:38:03 Error: [cast/client] [CastReceiverChannel] Failure to start application 6242A3BE on device: {
    "reason": "CANCELLED",
    "requestId": 953,
    "type": "LAUNCH_ERROR"
}
10/21 11:38:03 Error: [cast/client] [Chromecast-Audio-8230aa5b68bd1dd2b236f4a6e9a42029._googlecast._tcp.local] Failure to start Roon App on device

I experience the same issues both enabling and casting to the Nest Audio speakers and cast groups in our home. I have restarted the Roon service, as well as the entire server, as well as the Chromecast Audio. I have disabled the firewall on the box. This is a multi-function server with 32GB of RAM. Home Assistant and a few additional Python microservices I’ve written have no issues connecting to or maintaining connections to the cast receivers, so I am confident that networking and the network topology is not an issue here. All devices are on the same subnet. I do have a box of Google Ethernet Adapters for the CCA, so I can utilize one if you’d like, although I experience the issue on all of the cast receivers and groups I’ve tested with.

Thanks,
William

3

Update: I’ve now uninstalled the Roon server, dumped the old database, killed the Plex server running on the same box, and reinstalled the Roon server with no change in the behavior. After banging on the Enable button for a few minutes, I can usually get the Chromecast Audio to enable. When I select the device’s zone, I can always connect to and change the volume of the device from Roon.

Now when attempting playback, I’ll occasionally get a pair of server log messages similar to the following:

10/21 16:09:27 Trace: [push] restarting connection (Connection timed out)
10/21 16:09:27 Trace: [push] retrying connection in 422487ms

The client will usually fail silently but occasionally return the message Audio device refused to switch input to Roon. although the Google Home app always shows the device as Playing Roon after a failure to playback.

Just to reiterate, I serve 24/96 LPCM streams coming off of a Benchmark ADC1 to these same Chromecast devices almost daily and have never had any issues establishing or maintaining a connection. Any support you can lend will be very much appreciated!

4

@suppport, this has been sort of a bummer of a trial period given the above. Any chance I’ll receive any help before my trial runs out (other than the daily marketing e-mails about fun things to do with Roon)?

Thanks,
William

5

Hi William (@slimulus),

Thanks for reaching out! We are looking into an issue with Chromecast playback stopping after some time, but your symptoms here sound a bit different, in the sense that you cannot enable the zones altogether.

Have you by any chance tried to run the Roon Core on a standard Windows or Mac PC yet? If you have one around the house, I would give this a try just to confirm if the issue only impact the Ubuntu box:

  • Open Roon on the other PC you wish to try as the Core
  • Roon Settings -> General
  • Disconnect
  • On the “Choose your Core” screen, press “Use this PC”
  • If asked to Unauthorize, you can go ahead and do so. You are limited to one active Roon Core at a time but you are free to switch between them as often as you’d like.
  • Verify if the same behavior occurs on the different PC
6

Thanks @noris. Sure enough, switching the core to a Windows PC does allow the Chromecast devices to be enabled and played back (mostly) without issue. I do experience a playback issue that I believe I already saw reported where after pressing play, I have to press pause on the media controller and then press play again in order for playback to actually begin, but this does appear to be entirely separate from my original issue on the headless Ubuntu server.

Is there any way for me to get more verbose logging on the server? The logs that I’ve been watching don’t contain much, if anything, that seems particularly useful. The Windows PC is connected to the same subnet as the headless Ubuntu server; the topology is as simple as it could be with a single subnet for all devices. The Ubuntu server is connected via ethernet to the router.

7

Hi @noris, this looks like my issue:

Disabling the multicast container (or home assistant altogether) resolves the issue for me, so this is definitely an issue created by the older version of zeroconf in the HA multicast container. I’ll update this thread with my findings, but you can consider it resolved, as this is not a Room issue.

1 Like
8

Hi @slimulus,

Thanks for testing the Windows PC and for confirming that the issue is only occurring on the Ubuntu box!

It does sound like the multicast container is causing the issues, and I’m happy to hear that disabling the container resolved this behavior!

9

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.