Losing Audio Zone in 1.2

Only to report back that roon played for about 5 hours without issues. Only stopped it because I had to leave.

When I came back I played a bit more with my HQPlayer trial and when removing this from the networked players all devices (core) disappeared, but that is something already reproduced by roon.

After restarting roon all devices on the core were back again.

That’s confusing indeed, @allinedis :slight_smile:

We haven’t made much progress on this in the past ~12 hours, but not for lack of trying. Last night, set up four remotes (2 macs, 2 pcs) all with local zones and left one from each platform playing, and one not playing with a Windows server. In the morning all four machines had their zones, and the playing ones were still playing 12 hours later :confused:

Then ran down some theories related to power management–since failures after 10-20 minutes that aren’t networking related are sometimes related to power management…no dice.

@geoff_coupe reported that high-res seemed to make things worse, so we’ve switched to using 192k in our testing.

In his logs, the failures happen within 10-20 seconds after networking events where his operating system reports a connectivity change. Shortly after, connections between the machines start timing out and (for some reason) fail to recover on their own. The next step is to try to synthetically produce similar behaviors at the networking level, since my network doesn’t produce those events on its own.

@crmanitly is having issues within a single machine, and @allineedis seems to be crashing (or seems to have been crashing). So there isn’t exactly a clear pattern here.

As per my previous tests, have you set up your test system to do the following as a test

Windows Server On: But NOT sending any Music or Data to any Remote or Network Endpoint

Mac / Windows Remote [or Both]: Simply allow them to sit there without any music playing for 20 minutes plus and see what happens as regards the Local Zone on the Remote

With the Remote(s): Also try queuing 5-6 Tracks that play for a total of approx 20 plus minutes…and then monitor what happens when the last track finishes playing…[Important Note: Radio must be switched OFF for the Local Zone in which the above Queue is created, so that the Queue finishes and ‘resets’ its status]

Assuming any issues, then have a look at the Logs to see what may be happening

Windows Server On: But NOT sending any Music or Data to any Remote or Network Endpoint

I set this one up last week when we were first discussing it, and was unable to reproduce. I haven’t done that exact test since. It is worth repeating now that I have a larger variety of remote machines up and running. I will do that.

With the Remote(s): Also try queuing 5-6 Tracks that play for a total of approx 20 plus minutes…and then monitor what happens when the last track finishes playing…

I have this crash trapped in a debugger right now. Working on unraveling it :slight_smile:

Just so as you know, I have done the exact two tests as above using

2 different Roon Server machines and Roon Databases etc

Using 4 different Remotes [Win and OSX]

Using my Home Network…but also a completely independent Test network using Ethernet cabling only [no Wifi] with no other non-Roon devices attached

All of those tests reproduced the issue, I presume?

Should also add that if I keep the Server “busy” in ANY way, then the above issues [Zone Loss] do not occur…e.g.

  1. Server sending Music to Network Endpoint
  2. Force Server to perform a Rescan on a Watched folder
  3. Add a “new” watched folder to the Server

Basically: If Server is “busy”, then No Remote Local Zones lost…

Sorry…Yes, Issues are reproducible, even when using 2 different Servers…4 different Remotes…and 2 different Networks [and “Router” brands]

Is your music on a NAS?

Can’t imagine why that would be related to zone dropping, but mine is on a locally attached disk…

Maybe I should try a second windows server machine, and this time set it up with NAS storage. Change things up a bit.

My main Music Store is on a NAS…and that is what I used for tests during the week when we communicated

However, the tests above apply to Music on a NAS…as well as Music on the same local drive on the Server machine [subset of the main music library]

Certainly not against you trying any permutation / combination…but it’s important to note that even AFTER the Remote loses its Local Zone, I can still

a) See and Browse by Library on the Server [Library on NAS…as well as perform any Search or Focus etc as normal

b) Use the Remote to play music to an MS200 Endpoint

Summary: I’m not sure if the Music being on a NAS is an issue…as the NAS Library is still Searchable and Playable

Running into the same issue here after upgrading to 1.2. Not sure if you need the log files or more data points?

My Setup:

Music is on a NAS, Roon server runs on a dedicated Windows 10 box, wired GigE. Output is USB out of the Roon server box.

Control can be either Mac, Surface or iphone, same result, music stops playing.


Just sent you some instructions for getting us logs @jdineshk. Thanks for the report, and sorry for the trouble!

1 Like

Left a couple of remotes talking to an inactive server for about four hours–this time using a different install + server machine than the one that I was using before. All zones are present and accounted for, I’m afraid.

I didn’t mix in the NAS yet. That’s next, but for the reasons you mentioned, I don’t think it will change anything…

I’m going to be trying some further tests on my system today - basically try to replace my current network switch - that may be the weak point in my current network topology.

One thing that’s probably worth mentioning is that I’m seeing the audio zones drop out on specific machines e.g. the system output zone, or a Dragonfly zone, which is plugged into that specific machine will drop out randomly. And the interesting thing is that I don’t need to have music playing to those zones - monitoring the list of zones panel on any machine will show the zone disappear and then reappear a few seconds later…

Still looking stable at my end. Left the core running all night nothing playing and all audio options were still present this morning.

Accidentally switched of the DAC, which obviously results in the stopping of the ASIO driver (normal behaviour). When switching the DAC back on all audio options were present, but roon skipped through a chosen Tidal playlist. Slowly song by song and would not play anything. Only after restarting the core, everything worked again.

Cannot recall this behaviour from 1.1 since I often let the core run all night and only switch the DAC on when I am going to listen to music. Probably not related, but wanted to mention it anyway. I am away for a few days, so I cannot contribute anything during that time.

Well, I’m stumped. I’ve been focusing on one machine (a desktop PC with Core i5-4660) that regularly drops audio zones local to the machine (even when music is not playing to them) in an attempt to track down the cause of this issue.

Tried swapping out various bits of the network (and cables) to no effect. Uninstalled/reinstalled Roon. Tried it against a different Roonserver. Been trying stopping various software services/applications running on the PC, and still can’t affect the issue. I haven’t got a clue as to what’s going on here.

Well, at least my main Roon endpoints (Raspberry-based) to my HiFi and home cinema systems are working perfectly…


Thanks for the update. I agree that the issue with recovering after ASIO disconnect probably isn’t related. Will still take a look.


Ok. Thanks for trying. This is a confusing one. We will keep at it, and I’ll let you know if I think of anything else.

I lose all audio zones when I disconnect from my VPN service and then reconnect to a different server while music is playing. This is with no networked audio devices. Just the most basic setup; roon on Windows 10 local machine with USB DAC. Everything’s fine after restarting.

Not sure if this is related but hopefully this helps isolate the problem.

Hey guys, we’ve made some progress on these issues. It’s hard to say whether we’ve fixed every variation, as similar symptoms can often be tied to very different issues.

That said, we’re getting ready to release an update with a bunch of fixes, so it would be great if everyone could let us know how it goes with the next release.

Keep an eye out for the update, and if you’re still having problems, be sure to let us know. Thanks all!