Any firewalls active? If so, can you try turning them off and letting me know how it goes?
@mike - every PC/laptop/tablet and the server itself has Windows Firewall running.
Do you want them all off (gulp), or should I just try the server first?
I note that the server has firewall rules for (inbound UDP/TCP) for raatserver, roon, and roonappliance; and (outbound any protocol/port) for Roon appliance and RoonServer. Is that what there should be?
Thanks.
Turned of virusscanner and Windows Firewall, no difference.
Did a restart for the x time and now the zones were back. But…, as soon as I disabled 1 of the available options (in my case McIntosh WASAPI, which still does play nicely with roon), all options disappeared. The only option that is persistently staying alive is my squeezebox.
Let’s try turning them all off and see if things are better. If they are, we can add firewalls back in one by one and get a sense of where things are breaking.
@allineedis @Johan_Strypsteen – I’d like to get some logs from while you’re experiencing with the firewall off. I’ll be in touch via PM.
Same problem here: dropouts every few minutes (or less) since upgrading to v1.2. Audiozone needs to be reselected (after it re-appears in list).
Surface Pro W10, connected via wifi to Mac Mini with music database.
Thanks @mike. I’ve tried to simplify the problem by just having one instance of Roon actually playing music. This is what I have set up for the test:
- Roon on Desktop with i5-4460 running Windows 10 Pro version 1511
- Roonserver on server with i3-4130 running Windows 10 Pro version 1511
- Roon on latop with i7-6500U running Windows 10 Home Insider Preview 14316.1000
The Desktop is used to play music to the system output of the PC itself. The laptop is just used to display the list of currently available zones. There are four; the desktop, the laptop, and two wired RoonBridge endpoints (RPi3 + IQaudIO DAC+ and RPi2 + HiFiBerry Digi+)
I have turned off the Windows Firewalls (for the Private zones) on all three Windows devices.
The result is that I still lose the audio zone on the Desktop PC for a second or two. This happens every 10-20 minutes, and when it happens, I see the zone disappear from the list displayed on the laptop for a few seconds, and then it’s back. This causes the currently playing track to stop, so I need to restart it, and then it carries on until the next time the zone drops.
I have a second laptop using the Remote Desktop app to monitor Task Manager running on the server. This doesn’t show anything untoward. Roonappliance is the most active application on the server, consuming between 3.3% and 5% CPU. Even when something heavy kicks in (e.g. the Antimalware service executable, which consumes about 30% CPU), Roon carries on. I can’t see anything to tie it to the dropout issue at the moment…
Just a note to add that this dropping of the zone seems to affect my Windows devices when the zone happens to be the system output of the given device. If I use a Windows device to play to either of the RPi endpoints, then the zone does not get dropped as far as I have seen…
I’m having same problem - “no audio devices found” appears apparently at random during playback from NAS or Tidal. After a few seconds, device reappears and play button restarts playback. Dedicated music server, Windows 8.1. Currently controlled by attached keyboard, mouse, monitor. Tonight, audio device did not reappear after recent stoppage,and the list of devices is not longer seen in the Audio section of settings. is this being worked on?
A little further info - firewall is off, list of devices is repopulated by computer restart but not by a Roon restart
Yes, we’re working on it.
@crmanitly, it sounds this way from your description, but I want to be 100% certain: You are having this problem within a single machine–i.e. the Core and Output that are involved in the problem are on the same computer?
Everyone: please bear with us as we tease this apart.
Right now, we have several reports centered around a symptom, but it isn’t clear that the root cause of this is the same for all of you. We’re going through logs one at a time, analyzing the failures in detail, and and attempting to fix what we can. In parallel, we are trying to reproduce the issues here.
Issues like this are tricky–they can be very difficult to reproduce, and can be dependent on audio hardware or networking details, some of which we will not be able to reproduce exactly in-house. Any information that might help us reproduce these issues would be much appreciated–our “hit rate” on fixes goes way up for bugs that we can see in front of our face.
I do not want to make the first point-release of 1.2 without addressing this, but at the same time, we really need to roll out a build by mid-next-week since the list of other issues that have already been fixed is growing, and we can’t have people waiting too long. I am hoping that we can get a handle on the problems in this thread over the weekend.
@mike will be PM’ing everyone to collect logs soon if he hasn’t already.
@allineedis, I think I see two crashes in your logs:
- One that occurs when disabling devices in settings
- Another when RAATServer is interacting with the McIntosh ASIO driver–usually a few seconds after we intiialize the driver.
The crash while disabling devices, we have reproduced based on what we see in the logs, and we have prepared a fix for it. This will be in the next build.
The McIntosh stuff is a little bit more mysterious. It looks like it might be crashing in the ASIO driver itself, but it’s really difficult to tell based on logs alone. In the interest of isolating this to that area, it might be worth trying to:
- Disable the McIntosh ASIO driver completely in Roon
- Restart all of your Roon processes
- Avoid disabling devices in audio settings
- See if things are more stable
I did notice that you sometimes have your McIntosh device activated as System Output and as an ASIO zone at the same time. This does not cause crashes with ASIO devices I have here (unfortunately, we have no McIntosh gear), but it’s the kind of thing that the authors of that driver may not have anticipated, so it would be nice to remove it from the equation and see if that has any effect.
@brian I disabled the ASIO driver. Four possible zones are available, all disabled.
Only thing is that the ASIO driver was the only thing working, so no music anymore for now. All other 3 options do not work with my McIntosh MA7900 in combination with roon. The for options apear stable now.
As for seeing 2 McIntosh devices, I can only think of that I sometimes when a roon update is rolled out enable the McIntosh USB Audio option to see if roon was able to get a workaround working and I then forget to disable it. It never caused an issue as far as I know.
@mike with Roon 1.2, I am having the same issue with a MacMini with a TV monitor. My router is an AirPort Extreme ac. The MacMini is both core and output to a Weiss DAC292 via FireWire. iPad is control running the latest iOS Roon version released a few days ago. The iPad also continually loses connection. Error message: “Remote Connection. Waiting for remote library…”
I checked the firewall status in OSX System Preferences. It is turned off for all applications.
After updating to 1.2 yesterday, I could not play 96 or 192 content and 88 and 178 hHz content was down sampled to 44 kHz. Today these sampling rate issues resolved themselves.
Some of my Roon playlists have tracks missing from them. The tracks exist on the album view.
Jeff
OK, I could not sit in a silent house, enabled only the ASIO driver, after about 15-20 minutes (4-5 songs) the ASIO driver disappeared, music just stopped, roon displayed “select an audio device” message. The other 3 options, were still available.
After restarting the ASIO option is back again.
Disabled the ASIO option again, restarted and will leave roon running for a while to see what happens.
Now I am lost. Left roon with everything disabled (approx an hour) nothing happend or let’s call it stable.
Enabled the McIntosh ASIO option again and am listening now to an album already for almost an hour again and it all seems stable.
Have no clue what is happening since it not consistent.
EDIT: 2 hours more and still going, 3 hours in total…
@crmanitly, it sounds this way from your description, but I want to be 100% certain: You are having this problem within a single machine–i.e. the Core and Output that are involved in the problem are on the same computer?
Yes, Brian. The CAPS microZuma I am using is doing Core, Output and Control. Thanks for your efforts and I apologize for my tardy reply - I, like Rob, could not sit in a silent house, but I went to bed!
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 
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 
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.
@brian
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