In this case: Raspberry Pi with roon bridge (ropieee).
Description of Issue
I am running Roon on macOS as controller application.
One of my clients is a Raspberry Pi running Ropieee; I use it to occasionally listen to some music to fall asleep to in my bedroom.
This Pi is powered off automatically after the playback stops.
Every time I bring up the macOS Roon application the next day it is hung and can only be quit by using “Force Quit”.
It does not to be related to a specific macOS release/version - I’m running Ventura now, it definitely happened with Monterey the same way.
Steps to reproduce:
RasPi with Ropieee powered on and ready.
Roon (up to date version) running on macOS (on a MacBook Pro).
Ropieee is selected as “audio zone” in Roon.
Choose some Album; start playback
optionally: activate the sleep timer to stop playback after a set time
After playback starts, put the MacBook into sleep mode; the Roon application stays running (the application window may be closed through cmd+w).
(time passes, playback finishes, the RasPi is powered off by cutting the power supply)
next day: wake up the MacBook, bring up the Roon application window
application freezes and can only be quit through “force quit” as it does apparently not get that the Ropieee client has disappeared.
This may happen with other endpoints as well.
I think the issue might be that the Ropieee client is powered off while the controlling application is not active (in the sense of “getting any CPU cycles at all” since the MBP is in sleep mode) but still “running” and it does not undergo some kind of initialization process after the MBP is woken up.
So from the application’s view, the endpoint just suddenly disappears completely during playback (and the wall clock time skips a few hours).
Thank you for your patience in awaiting an official response from Roon. I would also like to thank you for your verbose descriptions in your completing the support template! We love that!
It may seem generic but I’d like to see what happens when you have a fresh instance of Roon and RAAT. If the issue occurs afterward, we can take a specific date/time instance and see what the diagnostic logging shows for the issue.
One other thing we can test is Mac’s energy saver settings. Does any of this occur with the settings I provide in my screenshot? I am on a Mini so there may be other settings you need to look at if you’re closing the lid on a Macbook.
I have gifted myself with a new MacBook last week, migrating all the data from the previous machine.
So far, I have not been able to reproduce the issue - I only tried once, though.
If it occurs again, I will set up a clean instance as you suggested and follow up.
As for the “wake for network access” setting - that’s one I intentionally have set to “off”.
Just as a FYI: it happened again yesterday, this time the output device was a USB DAC attached to the MacBook which I turned off at one point while Roon was running with the queue paused (I was streaming one of the Roon Daily Mixes, so no local music files involved - I don’t think the source material/location is a factor in this).
Bringing Roon up at a later point (“un-minimizing”) showed the purple “select audio zone” button at the bottom (as expected) and the infamous macOS “beach ball”, so I could only force quit the application.
I have tried to reproduce my steps in order to find a more efficient way to recreate the issue, but I have not yet succeeded.
There may be some lengthy timeouts involved.
