Include your operating system and machine info (Model, CPU, RAM)
Networking Gear & Setup Details
Your network gear (model of routers/switches) and if on WiFi/Ethernet
Connected Audio Devices
Specify what devices you’re using and their connection types, like USB/HDMI/Chromecast, etc.)
Number of Tracks in Library
Tell us how large your music library is, eg. “30,000 tracks”
Description of Issue
Bumping this for visibility. This exact issue has been happening to me for the past few weeks as well. A few times/day music will stop, I’ll receive the same progression of messages as the OP, and will be asked to select a different core. 50% of the time I can select the same core (and it says it’s available) and life continues until the next round of "uh oh"s, the other 50% I have to restart the core.
I’ve seen this issue on both of my cores, one on a Synology and one on a MBP, so it’s not isolated to any one platform.
Best I can tell it started happening with the last update to 970. I just upgraded to the latest release today, 987, and will share if the issue goes away.
I just tracked down the cause of this in my environment: I was running two cores as I was migrating from one core (NAS) to a new core (MacBookPro). I wasn’t trying to use two cores at once, and only one was Authorized, but I had both running as I was bouncing back and forth for backups and restores. It wasn’t 100% repeatable – sometimes the playing core would stay up and play for days, sometimes it would “Uh oh” every track. I was able to track it down during one of the “Uh ohs” per track by looking at the logs and seeing two things:
Chromecast endpoints were constantly going up and down. I was seeing this in the UI (Settings → Audio) as they would be listed as available for a few seconds, then go away, then come back, etc. The log entries looked like this:
07/12 13:05:45 Info: [transport] destroyed zone Google Mesh: Music Room was playing? False
07/12 13:05:45 Trace: [zone Google Mesh: Music Room] Suspend
07/12 13:05:45 Info: [zone Google Mesh: Music Room] Canceling Pending Sleep
07/12 13:05:45 Info: [zone Google Mesh: Music Room] Canceling Pending Sleep
07/12 13:05:45 Error: [cast/client] [Google-Cast-Group-535A3BD7EAD24E0181F0DEEC804A52A5-1._googlecast._tcp.local] Exception writing message to stream:
07/12 13:05:47 Info: [cast] lost device CastDevice[DeviceId=Google-Cast-Group-535A3BD7EAD24E0181F0DEEC804A52A5-1._googlecast._tcp.local, Name=Google Cast Group, Address=192.168.1.28] because it disconnected
I caught the following in the logs of my MBP core, which I thought was odd b/c the Synology isn’t doing anything except running a core.
As long as the Roon binaries are running, you can look at the logs to get the version. It’s not ideal, and I didn’t see a way to ask the actual binary for a version, but this works:
100% agree. I estimate that I spend ~4 hours per week fighting with Roon to either fix issues, ask for support on the forums, doing my own troubleshooting, etc, which is literally insane for a piece of software that I pay for. Imagine if you had to spend 4 hours per week keeping Netflix up and running? No one would stand for that, no idea why the Roon community tolerates it.
Before 1.8, Roon was amazing. Since 1.8, Roon has been so unstable it’s basically become unusable, which is crazy sad b/c they basically own this market.
I renew in about 10 months and will be spending that 10 months looking for an alternative that supports streaming to the endpoints I invested in before 1.8. If I’m going to spend this much time on keeping music streaming up and running I’d prefer to use OSS software where I know what I’m getting and/or have the ability to fix things for the broader community rather than my own env.
I’ve split this into a fresh thread in order to allow proper attention to your issue. In order to best assist you, we’ll need to you fill out the setup template I’ve copied into your first post.
Please be as specific as possible, this information is immensely helpful for the support team
