Cannot start group, music stops, Support ticket dead-end. "Get Help" says contact manufacturer

Support
1

Latest build Roon Server version 2.55 (build 1559) running on Ubuntu server.

Symptoms:

  1. Cannot start Airplay group. Saw pause icon but time not advancing in song. No sound.
  2. Could not start RAAT speaker. Same behavior
  3. Ungrouped speakers and COULD start ONE Airplay device. Finally got music playing
  4. Music stopped after a couple minutes. This unfortunately now occurs frequently
  5. Could not send support ticket:
    • questions not relevant but I tried.
    • filled out form and got message “Contact Manufacturer”. End of Get Help (e.g., go away) as I could not submit a ticket.
  6. created this community post

More detail:

I started music on an Airplay group this morning *** at 9:11 am on 9/24 according to log ***

No sound on Airplay devices, Pause Icon shown (Roon thinks playing apparently). Song position not advancing.
Tried RAAT on my KEF LS50 wireless. Same behavior.
Ungrouped and played on one Airplay device. Yay, music! This worked the previously as well.
Music played for a short while then stopped. I was able manually resume. This is not a unique occurrence with build 1559.

NO PROBLEMS prior to change to networking code. (Very pleasant history and experience BTW.)

Tried to submit support ticket. Questions not relevant then received message to contact the manufacturer which terminated my attempt at a support ticket.

Unable to submit support ticket so I created this post.

I have the log file preserved.

2

Hi @Rob_Farber,

Thank you for your post. During the particular incident you described at ~9:11, the KEF’s Airplay receiver appears to have logged Airplay1 handshake commands while the other two devices are relying on Airplay2. Do you have Compatibility Mode toggled on for these Airplay Zones in Roon Settings → Audio → Device Setup?

More broadly, in the last few days, logs show the KEF’s Airplay receiver returning pairing failures when the Airplay group re-syncs for playback during track transitions. The next track is already buffered, but Roon doesn’t receive an expected RTSP request (Apple’s real-time streaming protocol) from the KEF’s Airplay stack. Playback has started from Roon’s perspective, but within Airplay, the KEF’s connection times out and it stops responding. Eventually, Roon tears down playback too, unless manual intervention (hitting the play button) forces Airplay to resync once more and it succeeds.

When attempting to play to the KEF using RAAT, the KEF does not respond to RAAT’s initiation requests five times before the connection fails.

To confirm the topology involved, does the KEF rely on a separate mesh node/router from the rest of these Airplay receivers?

I’d recommend adding all of these Airplay Zones to the Apple Home app, if you have an iOS device. This will allow Apple to more directly manage device discovery, and might relieve some of the session-initiation issues we’re seeing Airplay in logs.

Thanks for your patience. We’ll continue to investigate.

3

Hi Conner and thanks for your reply.

Yes, compatibility mode is enabled on all Airplay devices.

No, my network is not a mesh network. No reported errors or flakiness from my network devices, All seems to work fine with tidal and the Sonos app. I was using that while the disappearing roon devices was occurring with the last roon version.

No issues prior to the last revisions that changed the network stack.

FYI: Kudos on years of reliable music from roon as I don’t think you get many positive comments doing support. I’m a lifetime subscriber that only recently needed to submit support tickets.

Not a member of the Apple ecosystem.

I hope I didn’t confuse things in the logs as I tried using the Kef in different modes to “restart” the roon music. Similarly I could not use the Sonos app to reset things for roon. (This worked sometimes for the disappearing devices issue in the last release.)

From your comments, you highlight issues with the Kef LS50 wireless. I seem to recall the same “no music” with just the two Sonos speakers (without the Kef in the group). For reliability, should I NOT include the Kef in my group at this time? Is it the problem child?

As a security question, you can access my logs remotely? My concern is that I see many attempts to access the exposed roon arc port by blacklisted IP addresses. Y’all are popular. How secure is your remote access? Should I put roon and my roon devices on a separate VLAN?

4

A follow up:

At 20:29 or 20:30 9/24/2025 playback to a single Sonos Airplay device stopped. I was able to hit play again to resume. I believe others have reported this problem.

5

Hello @Rob_Farber

Thank you for the update.

We noticed the following message in the Roon logs:


Sep 24 20:30:45 roon start.sh[998]: System.Net.Sockets.SocketException (104): Connection reset by peer

Sep 24 20:30:45 roon start.sh[998]: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)

Sep 24 20:30:45 roon start.sh[998]: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)

Sep 24 20:30:45 roon start.sh[998]: at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)

Sep 24 20:30:45 roon start.sh[998]: --- End of stack trace from previous location ---

Sep 24 20:30:45 roon start.sh[998]: at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)

Sep 24 20:30:45 roon start.sh[998]: at Sooloos.RnetJsonClient.<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)



09/24 20:30:36 Trace: [dbperf] flush 0 bytes, 0 ops in 3 ms (cumulative 62767901 bytes, 35956 ops in 12528 ms)

09/24 20:30:36 Debug: [easyhttp] [5659] GET to https://api.roonlabs.net/metadatatext/1/blobs?objectId=174:1:&type=description&sourceLangs=Rovi-albums:en,Wikipedia:en,Rovi-artists:en,Rovi-compositions:en&c=tidal-us&tidal=max returned after 530 ms, status code: 200, request body size: 0 B

09/24 20:30:38 Warn: [rnet/RnetJsonClient] failed to connect No route to host

09/24 20:30:38 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] client connection failed. Retrying in 500ms

09/24 20:30:38 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connecting (attempt 2)

09/24 20:30:41 Warn: [rnet/RnetJsonClient] failed to connect No route to host

09/24 20:30:41 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] client connection failed. Retrying in 750ms

09/24 20:30:41 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connecting (attempt 3)

09/24 20:30:44 Warn: [rnet/RnetJsonClient] failed to connect No route to host

09/24 20:30:44 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] client connection failed. Retrying in 1125ms

09/24 20:30:45 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connecting (attempt 4)

09/24 20:30:45 Info: [remoting/serverconnectionv2] Client disconnected: 192.168.1.199:58210

09/24 20:30:45 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] lost client connection. Retrying(0)

09/24 20:30:45 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] connecting (attempt 1)

09/24 20:30:46 Debug: [easyhttp] [5665] POST to https://api.roonlabs.net/device-map/1/register returned after 197 ms, status code: 200, request body size: 11 KB

09/24 20:30:46 Trace: [devicemap] device map updated

09/24 20:30:47 Warn: [rnet/RnetJsonClient] failed to connect No route to host

09/24 20:30:47 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] client connection failed. Retrying in 1687ms

09/24 20:30:48 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connecting (attempt 5)

09/24 20:30:50 Info: [stats] 15734mb Virtual, 3563mb Physical, 1362mb Managed, 2201mb estimated Unmanaged, 870 Handles, 189 Threads

09/24 20:30:50 Warn: [rnet/RnetJsonClient] failed to connect No route to host

09/24 20:30:50 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] client connection failed. Giving up

09/24 20:30:50 Trace: [raat] [sood] Refreshing device list

09/24 20:30:55 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] client connection failed. Retrying in 500ms

09/24 20:30:56 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] connecting (attempt 2)

09/24 20:31:00 Debug: [easyhttp] [5666] POST to https://api.roonlabs.net/device-map/1/register returned after 192 ms, status code: 200, request body size: 11 KB

09/24 20:31:00 Trace: [devicemap] device map updated

09/24 20:31:04 Trace: [broker/accounts] [heartbeat] now=9/25/2025 3:31:04 AM nextauthrefresh=9/25/2025 4:30:35 AM nextmachineallocate=9/25/2025 3:56:04 AM

09/24 20:31:05 Info: [stats] 15325mb Virtual, 3563mb Physical, 1359mb Managed, 2204mb estimated Unmanaged, 869 Handles, 135 Threads

09/24 20:31:06 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] client connection failed. Retrying in 750ms

09/24 20:31:06 Trace: [raatserver] [RaatServer Pixel 9 Pro @ 192.168.1.199:9200] connecting (attempt 3)

09/24 20:31:10 Trace: [musicpowerstate] music has not been playing for 5 minutes, allowing idle sleep

09/24 20:31:16 Trace: [raat] RAATServer discovered: RaatServer TEWORK @ 192.168.1.174:9200

09/24 20:31:16 Info: [raatserver] GOT SERVER :: @ 192.168.1.174:9200 TEWORK PROTOVER=1 RAATVER=1.1.39

09/24 20:31:16 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connecting (attempt 1)

09/24 20:31:16 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.174:9200] connected

09/24 20:31:16 Trace: [rnet/RnetJsonClient] SENT {"request":"enumerate_devices","subscription_id":"0"}

09/24 20:31:16 Trace: [remoting/brokerserver] [initconn 192.168.1.174:59351=>192.168.1.62:9332] Connected

09/24 20:31:16 Trace: [remoting/brokerserver] [initconn 192.168.1.174:59351=>192.168.1.62:9332] Resumed Session

09/24 20:31:16 Warn: [remoting/remotingprotocolv2] stealing a perfectly good connection...hmmm

09/24 20:31:16 Trace: [remoting/remotingprotocolv2] resume send 4331 messages, 658KiB

“No route to host”

This indicates that the Core tried to connect to an endpoint, but the operating system couldn’t find a network path. This is purely a network-level issue — for example, the endpoint could have been temporarily offline, disconnected from the network, or blocked by routing or firewall rules.

In the logs, we can see that after a few failed attempts, the endpoint becomes available again (e.g., RAATServer discovered @ 192.168.1.174:9200) and the Core successfully connects. This shows that the issue is temporary, not permanent.

We’ve also seen similar messages for your Pixel 9 Pro, which suggests some instability in the network connection (either Wi-Fi or LAN).

To help us pinpoint the cause, could you clarify:

  1. Is the client connected via Wi-Fi or Ethernet?

  2. If Wi-Fi — have you tried switching between frequency bands (2.4GHz vs 5GHz)?

  3. Are there any rules in your router or firewall that could temporarily block access?

  4. During the issue, does the client disappear from your home network entirely (e.g., not responding to ping or Fing)?

This information will help us identify whether the problem is related to the network setup or temporary connectivity issues.

We can’t access logs directly; we can send the request to your Roon server to upload the logs to our storage. This is completely secure.

6

Answers to questions:

  1. These logs make sense to me.as the roon clients reference in the log are connected to WiFi but I believe they were either asleep or in power down mode at that time

  2. 5G. (Caveat: the pixel 9 pro can change bands or to cellular if I am moving about my property, but I was not moving then or outside.)

  3. No.

4: These log entries make sense to me as both TEWORK and the Pixel 9 Pro roon remotes were either in low power mode or sleep mode at that time the music stopped. FYI: I was using a tablet via 5G Wi-Fi at that time and did not experience any issues nor did the speaker have any dropouts.

  • Client TEWORK is a PC that goes to sleep to save energy. I believe that in that state it would not be responsive and any network request to it should fail. I don’t recall if I shutdown the roon remote (windows) application on that system prior to it going to sleep or if I let it wake up.
  • However, I did power the PC up to send my reply about the issue. I believe I used the roon remote on that system to start the music again.
  • The Pixel 9 Pro also was in a power down mode as I was using a tablet. I don’t know the latency for it to wake up. I don’t recall if it was running the roon remote android app. I alternate between tablet and phone as I see fit.
  • I might have started my phone as well after the music stopped either activating roon remote or I started the app. Sorry, I don’t recall.

As a follow-up I checked and the opnsense logs were free of any errors, warning alerts or other concerning entries. All appeared to be running smoothly. I have not had any WiFi instability recently or if at all for many years, I do check it regularly and use all aspect of it daily.

Note that my Sonos amp is hard wired and not WiFi. It was not in use at that time but I think I have seen the music stopping issue as well when I am in that building (and using it).

Thanks for answering my security question. As you can tell I am security conscious. Is there any functionality other than the ability to pull my logs?

7

Hello @Rob_Farber,

Thank you for the update.

Opnsense may log general network failures or disconnections, but it usually does not track connectivity quality issues between clients themselves — so the absence of warnings there does not necessarily mean the Sonos was consistently connected.

I have searched the logs around the mentioned timestamp, as exactly at 20:30, I do not see any evidence of the playback, and here’s what I observed. Playback to your Sonos Five (AirPlay) actually stopped earlier, at 20:26:10, when the device disconnected:


09/24 20:26:08 Trace: [airplay/clientV2] [192.168.1.113] feedback Succeeded

09/24 20:26:10 Trace: [airplay/clientV2] [192.168.1.113] Sending TEARDOWN

09/24 20:26:10 Info: [airplay] AirPlay device disconnected: … Name=Sonos-347E5CD69D74.local, Model=Five

09/24 20:26:10 Trace: [zone old radio (airplay)] Suspend

09/24 20:26:10 Info: [zone old radio (airplay)] OnPlayFeedback Stopped

09/24 20:26:10 Info: [zone old radio (airplay)] Canceling Pending Sleep

09/24 20:26:10 Trace: [old radio (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [2% buf] [STOPPED @ 0:00] Unsquare Dance - The Dave Brubeck Quartet / Dave Brubeck

09/24 20:26:10 Debug: FTMSI-B closed file for ti/693ABC09; open files:0

09/24 20:26:10 Info: [audio/env] [zoneplayer -> stream] All streams were disposed

09/24 20:26:10 Debug: FTMSI-B ti/693ABC09 download status: AllBlocksDownloaded accessTimeout:True openFiles:0 prev:(AllBlocksDownloaded,True,1)

After this point, I don’t see any further playback activity until 20:34:13, when the Sonos Five reconnects and playback starts again:


09/24 20:34:13 Info: [old radio (airplay)] [zoneplayer] Starting playback

09/24 20:34:13 Info: [airplay] AirPlay device connected: … Name=Sonos-347E5CD69D74.local, Model=Five

Between these timestamps, there is no evidence of a software fault — the interruption comes from the device losing its network connection and then re-establishing it.

Based on the logs, the issue here relates specifically to the Sonos Five zone. Could you confirm again whether it’s connected over WiFi or Ethernet?

As the next step, please check if the device is running the latest firmware and, depending on the connection type, either ensure a stable Ethernet link or test by moving it closer to your access point.

Would you kindly explain in more detail what you mean by other? All information related to the diagnostic data available in our terms

8

Network connectivity does not appear problematic

True, the opnsense logs don’t reflect connectivity issues.

The previous roon response was concerned about the “no route to host” and “loss of connectivity” concerns raised for the two roon remotes. This was explained by their associated hardware being asleep or in low power mode. The opnsense logs supported this explanation given roon support assertation “This is purely a network-level issue” and “the issue is temporary, not permanent”.

Silent WiFi connectivity concerns

I’m not certain how to address the concern over silent WiFi connectivity issues except to note that they started with the (admittedly problematic) two recent roon updates to the network stack. Use of these speakers over WiFi has been stable with roon prior to that.

Topically: A temporary, short-term silent disconnect does not seem to explain my reported error that I could not restart music on the airplay group.

Answering your questions:

  • Yes the sonos speakers are connected via wifi.
  • Yes, the sonos speakers are running the latest firmware according to the sonos app.

Further info: The WiFi signal does not appear problematic

  • They have been in their position for years.
  • WiFi measurements (WiFi man) show they both have strong signals at their locations
  • There do not appear to be any conflicting 2.4 GHz signals (used by the Sonos). I get 75 -100 Mbps bandwidth by each speaker with speedtest (over 700 Mbps on 5GHz).

3rd party apps (tidal and sonos particularly) don’t exhibit issues:

No other application or device in my WiFi network exhibits issues. Both tidal and Sonos apps do not exhibit ANY issue when playing music on those speakers as a consistency check. Admittedly this is using sonos protocol and not airplay. Recent community posts indicate others are seeing the stopping play issue with these updates as well, but I don’t know if they are related to my music stoppages.

Noted time discrepancy:

Likely my attributing the loss of music to a song change or characteristic of the song rather than a playback failure until enough time passed to make me notice the failure. Roon has been an excellent platform for background music until these recent issues.

9

I changed out the access point (AP) that serves the wireless speakers. Let’s see if that changes the behavior. :crossed_fingers:

10

My music stopped while I was monitoring my network and roon server this morning. I was able to click play to resume playback.

Here is the info I gathered …

Roon server reported
09/28 09:19:59 Trace: [volumewatcher] ev_VolumeChanged DidMount: /run/user/1000
09/28 09:19:59 Debug: [broker/filebrowser/volumeattached] found newly mounted drive at /run/user/1000
09/28 09:19:59 Debug: [broker/filebrowser/volumeattached] skipping /run/user/1000 because it is not a /dev/sd[0-9]* (mountline: tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=780844k,nr_inodes=195211,mode=700,uid=1000,gid=1000,inode64 0 0)

ubuntu reported

Sep 28 09:19:57 roon systemd[1]: Created slice User Slice of UID 1000.
Sep 28 09:19:57 roon systemd[1]: Starting User Runtime Directory /run/user/1000…
Sep 28 09:19:57 roon systemd[1]: Finished User Runtime Directory /run/user/1000.
Sep 28 09:19:57 roon systemd[1]: Starting User Manager for UID 1000…
Sep 28 09:19:57 roon systemd[284128]: Queued start job for default target Main User Target.
Sep 28 09:19:57 roon systemd[284128]: Created slice User Application Slice.
Sep 28 09:19:57 roon systemd[284128]: Reached target Paths.

All netgear RAX45 (in access point mode):
All logs are clean with no errors or anomalies. No reported wifi or network connectivity issues.

Very light usage via wifi connect PC:
No anomalies observed.

Opnsense:
All logs seem fine. No anomolies reported.

11

[Moderator Edit: New support topic merged into existing.]

What’s happening?

· Other

How can we help?

· None of the above

Other options

· Other

Describe the issue

Same time adding and deleting an airplay device restarts deleted device

Describe your network setup

Opnsense router, multiple rax45 APs, wired to sonos amp.

It correctly adds and deletes the zone as music correctly starts and stops. However it then adds the deleted zone back and starts playing music. Roon remote shows all zones (including the delete one) playing music.

100% reproduced on Android and Win11 Roon remote apps and consistent.

12

Hello @Rob_Farber

Thank you for the detailed report. Could you please reproduce the issue again and record a short video showing the behavior? This will help us investigate more effectively.

You can upload the video here:
https://workdrive.zohoexternal.com/collection/nqcgjac23027d90a441bda2c314de49d7958a/external

Thank you!

13

Hello @Rob_Farber

Thank you again for your patience. I understand this is frustrating, as you’re experiencing stoppages that don’t align with major errors in the logs we extract from your Roon Core.

Based on our complete analysis of your diagnostics, here is our current summary of the playback issues:

Analysis of Roon Core Logs

We have thoroughly analyzed the logs from your Roon Core, including the streaming engine and network communication details.

  1. Streaming Performance Was Flawless: Our analysis confirms that all content downloaded perfectly from TIDAL. We found no errors, warnings, or bandwidth issues whatsoever related to Roon obtaining the music. The entire song file was downloaded at extremely fast speeds and the playback buffer was full almost immediately. The Roon Core and your internet connection are not the cause of the interruptions.
  2. No Issue with Roon Remotes: Your explanation that your PC (TEWORK) and Pixel 9 Pro were in a sleep or low-power state is correct and fully resolves the earlier “no route to host” warnings. Those warnings were simply Roon noting that the sleeping control device was temporarily unavailable, and they do not affect playback on your speakers.
  3. The Invisible Problem: When your network gear (Opnsense, Netgear RAX45) logs are clean, it tells us the issue is highly localized to the speaker itself. A brief, silent micro-drop in Wi-Fi quality can be severe enough to cause the speaker to panic and issue a TEARDOWN, even if your robust network equipment doesn’t flag a total disconnection.

Next Steps: Isolating the Speaker’s Wi-Fi Sensitivity

Since we have definitively ruled out Roon software and the internet stream, we must focus on the wireless link to your Sonos speakers.

  1. Crucial Ethernet Test: Please temporarily connect one of your Sonos Five speakers directly with an Ethernet cable. Running this test is the quickest way to isolate the issue. If the wired speaker plays music flawlessly for a long period, we have confirmed that the root cause is entirely the AirPlay sensitivity to your 2.4 GHz Wi-Fi environment.
  2. Firmware Check: Please double-check that your Sonos speakers are running the absolute latest available firmware.

Thank you for your collaboration. By performing the wired test, we can isolate the problem to your speaker’s wireless performance.

14

A micro-drop on one speaker does not explain the original issues reported. Specifically, I reported:

  1. Cannot start Airplay group [after music stopped playing on group]. Saw pause icon but time not advancing in song. No sound.
  2. Could not start [music on] RAAT speaker. Same behavior
  3. Ungrouped [all] speakers and COULD start ONE Airplay device. [and] Finally got music playing.

Questions:

  • From the logs, I ask why is roon monitoring the root file system on my ubuntu server (e,g, /run/user)? I only have very specific folders configured in audio (can send screenshots). This is a red flag for two reasons:
    • The roon server has no business monitoring any folders on my system except the ones I specify.
    • It seems a remarkable coincidence that the only logged issue at the time playback stopped was during the roon server’s confusion and subsequent error handling concerning a new, invalid folder in /run/user.
*------------------------ From the logs ----*

Roon server reported
09/28 09:19:59 Trace: [volumewatcher] ev_VolumeChanged DidMount: /run/user/1000
09/28 09:19:59 Debug: [broker/filebrowser/volumeattached] found newly mounted drive at /run/user/1000
09/28 09:19:59 Debug: [broker/filebrowser/volumeattached] skipping /run/user/1000 because it is not a /dev/sd[0-9]* (mountline: tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=780844k,nr_inodes=195211,mode=700,uid=1000,gid=1000,inode64 0 0)

ubuntu reported

Sep 28 09:19:57 roon systemd[1]: Created slice User Slice of UID 1000.
Sep 28 09:19:57 roon systemd[1]: Starting User Runtime Directory /run/user/1000…
Sep 28 09:19:57 roon systemd[1]: Finished User Runtime Directory /run/user/1000.

-------------------------------
  • Is it true that a micro drop on one speaker will cause an entire grouped play to stop?
    • Note the issue was not isolated to just one speaker. Playback on the entire group stopped. If true. I postulate that this is a robustness issue with roon as a microdrop (very short, invisible, not logged by roon) will kill playback.
    • Question: Shouldn’t the roon server log that it is tearing down the group/speaker connection since playback stops?
    • Note: This issue started with the previous two roon updates. I had no playback issues previously over the last number of years.
    • Observation: No issues observed with grouped play with the Sonos or Tidal apps, which I used while roon fixed the disappearing devices issue.

My actions:

I am playing music from a folder on my server through a wired connection from the roon server to a Sonos amp playing music on speakers wired to the amp. However, I am also listening to roon streamed music on my wireless speakers.

  • Please confirm this will not invalidate my test? At this time I understand that a silent micro drop can stop playback on all the speakers in a group.
  • If true, will a microdrop also stop playback on unassociated groups/zones?

Answering your question: (confirmed previously), the Sonos app says I am running the latest firmware on all Sonos devices.

1 Like
15

Hi @Rob_Farber,

We’ve enabled some verbose logging to inspect the device announcements coming to/from Roon with Airplay.

At your convenience, please reboot RoonServer two times to ensure the new logging is activated. Reproduce the issue with adding Zones and let us know an approximate timestamp (or the name of the track that was playing).

This should equip our team to pin down what’s happening and establish next steps. Thank you again for your report.

16

Hello @Rob_Farber

Thank you for the update.

1. File system monitoring on /run/user
Roon is not actively scanning your entire root filesystem. What you are seeing in the logs is Roon reacting to mount events reported by Linux.

On Linux, services can subscribe to kernel and systemd notifications about new volumes being mounted or unmounted (for example, USB drives, network shares, or temporary filesystems like /run/user/1000). Roon listens for these events so it can detect if a new storage device with music becomes available.

In your case, Roon noticed that a new temporary filesystem was mounted at /run/user/1000, briefly checked if it might be valid storage, and immediately skipped it as “not usable.” This is expected behavior, and it does not mean Roon is crawling or indexing parts of your filesystem you didn’t configure as music storage.

2. Group playback and micro-drops
Yes, a loss of sync or a drop on one endpoint in a grouped playback chain can cause playback for the entire group to stop. This is a limitation of how group synchronization works across RAAT and Airplay devices.

3. Next steps

  • Please confirm whether this behavior (group playback stopping after a drop) is reproducible for you on demand, or if it only occurs sporadically.
  • If I understand correctly, when the playback is stopped, you are no longer able to start it via the same group?
  • We have enabled an additional diagnostic setting on your account. Please restart the Roon server two or three times and reproduce the issue again. After this, please share the exact timestamp here when the issue happens next time.
17

Thank you for your continued support.

I experienced a dropout and kept it up on my screen to report it should I see another. Our community then experienced a power outage and all my systems lost power.

With your latest support messages, I found the log entries recording during the dropout and prior to the power outage. I believe I found the incident in my logs and hope they contribute value. Happily I wrote down on paper the Beth Hart song that was playing when the dropout occurred. I include a log snippet below to help you find the incident in my logs.

Notes:

  • I was concurrently playing music from a folder on my server to a wired ethernet connected to a Sonos amp to eliminate variability in the network stack due to Wi-Fi. Playback continued on the hardwired zone until the power outage. Sorry if the concurrent play adds complexity to interpreting the logs.

  • I was able to resume playback on the Wi-Fi connected zones. I only saw the resumption of play (according to the server) without hearing any music at the time I posted my initial support issue.

  • None of my AP logs reported any issues at that time or any time before or after the incident.

  • Thank you for explaining the normal operation of the mount monitoring. While the debugging is not intended for public analysis, the message is concerning.

  • Thank you for enabling extended logging.

Incident:


10/01 14:22:32 Trace: [old radio (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:46/5:16] Just a Little Hole - Beth Hart

10/01 14:22:32 Trace: [ls50 (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:46/5:16] Just a Little Hole - Beth Hart

10/01 14:22:32 Trace: [office (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:46/5:16] Just a Little Hole - Beth Hart

10/01 14:22:33 Trace: [shop (airplay)] [LowQuality, 24/44 MP3 => 16/44] [100% buf] [PLAYING @ 0:27/4:44] Kentucky Woman - Deep Purple

10/01 14:22:37 Trace: [library] endmutation in 12ms

10/01 14:22:37 Trace: [old radio (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:50/5:16] Just a Little Hole - Beth Hart

10/01 14:22:37 Trace: [ls50 (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:50/5:16] Just a Little Hole - Beth Hart

10/01 14:22:37 Trace: [office (airplay)] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:50/5:16] Just a Little Hole - Beth Hart

10/01 14:22:38 Trace: [shop (airplay)] [LowQuality, 24/44 MP3 => 16/44] [100% buf] [PLAYING @ 0:33/4:44] Kentucky Woman - Deep Purple

10/01 14:22:38 Trace: [airplay/clientV2] [192.168.1.166] feedback Succeeded

10/01 14:22:39 Trace: [airplay/clientV2] [192.168.1.194] feedback Succeeded

10/01 14:22:39 Trace: [airplay/clientV2] [192.168.1.114] feedback Succeeded

10/01 14:22:40 Warn: [airplay/rtsp] IOException in RTSP request: Unable to read data from the transport connection: Connection timed out.

10/01 14:22:40 Info: [airplay] AirPlay device disconnected: AirPlayDevice[DeviceId=347E5CD69D74@Sun Room._raop._tcp.local, Name=Sonos-347E5CD69D74.local, Model=Five, IPEndPoint=192.168.1.113:7000]

10/01 14:22:40 Trace: [airplay] disconnected

10/01 14:22:40 Trace: [zone] old radio (airplay) received transport control from endpoint integration: suspend

10/01 14:22:40 Trace: [zone Sun Room (Sonos Five) + ls50 (airplay) + office (airplay)] old radio (airplay) + ls50 (airplay) + office (airplay) received transport control from Sun Room (Sonos Five): suspend

10/01 14:22:40 Trace: [zone Sun Room (Sonos Five) + ls50 (airplay) + office (airplay)] Suspend

My personal observations (YMMV, no comment required)

  • From a security standpoint, only the user specified folders should be examined. Under no circumstances should directories outside the path to those folders be examined.

  • I appreciate the complexity of supporting a hodgepodge of consumer Wi-Fi devices and networks. That said, perhaps Roon should be more aggressive in attempting to keep or reestablish a connection? My existence proof is qualitative being Tidal and Sonos had no dropouts when I used them over a period of days while Roon fixed the disappearing clients issue.

18

I went out and when I returned, the airplay devices disappeared (and they eventually reappeared). No issues were reported with my internet connection or in my RAX45 logs.

Sorry, I don’t know the time when it happened, only the time when I observed the incident.

Here are some of the log entries:

10/04 15:15:58 Info: [mdns/discovery] GOT TXT FOR 347E5CD69666@Office._raop._tcp.local with TTL 10
10/04 15:15:58 Debug: [mdns/discovery] [mdns/discovery] Device seen: Name=Sonos-347E5CD69666.local, DeviceId=347E5CD69666@Office._raop._tcp.local, Address=192.168.1.194, ResponderAddress=192.168.1.194, Port=7000, EndPoint=192.168.1.194:7000LastSeen=10/4/2025 10:15:58 PM, ExpirationUtc=10/4/2025 10:16:08 PM, TTL=10, GotSRV=True, GotTXT=True
Properties:
    model=Five
    pk=fa311a7a41e707f4f8d02d493232166de03cf2ff1d16173405519f85837af1c3
    serialNumber=34-7E-5C-D6-9D-74:1
    flags=0x4
    fv=p20.91.0-68261
    acl=0
    features=0x445F8A00,0x1C340
    srcvers=366.0
19

Lost devices again. This seems related to the elevated debug level.

10/04 20:12:05 Trace: [raatserver] [RaatServer TEWORK @ 192.168.1.163:9200] connecting (attempt 1)
10/04 20:12:05 Debug: [UpdateRemoteLocalTime] iso = 2025-10-04T20:12:03.3994372-07:00
   offset_utc_minutes = -420.000000295
   _remote_local_time = 10/4/2025 8:12:03 PM
   _process_local_time = 10/4/2025 8:12:05 PM
   _is_process_utc_timezone = False (off by -25200.0000008)
20

I have had a recurrence of the disappearing Airplay devices since the extended debug was enabled.

This morning the only devices that roon saw were my Wi-Fi connected Kef and Ropieee endpoints and my hardwired Sonos amp via airplay. Consistent with both Android and Win11 roon remotes.

Log info


10/06 07:19:07 Trace: [airplay] expired device AirPlayDevice[DeviceId=841715152AF0@Master Bedroom speaker._raop._tcp.local, Name=kef_one-841715152af0.local, Model=LS50 Wireless II, IPEndPoint=192.168.1.166:7000] because it isn't connected and hasn't been seen in 180s

10/06 07:19:07 Trace: [airplay] disconnected

10/06 07:19:07 Trace: [airplay] expired device AirPlayDevice[DeviceId=347E5CD69D74@Sun Room._raop._tcp.local, Name=Sonos-347E5CD69D74.local, Model=Five, IPEndPoint=192.168.1.113:7000] because it isn't connected and hasn't been seen in 180s

10/06 07:19:07 Trace: [airplay] disconnected

10/06 07:19:07 Trace: [airplay] expired device AirPlayDevice[DeviceId=347E5CD69666@Office._raop._tcp.local, Name=Sonos-347E5CD69666.local, Model=Five, IPEndPoint=192.168.1.194:7000] because it isn't connected and hasn't been seen in 180s

10/06 07:19:07 Trace: [airplay] disconnected

10/06 07:19:07 Trace: [airplay] expired device AirPlayDevice[DeviceId=D83ADDA45ADA@ropieee [RoPieeeXL]._raop._tcp.local, Name=ropieee.local, Model=Shairport Sync, IPEndPoint=192.168.1.107:7000] because it isn't connected and hasn't been seen in 180s

My wireless RAX45 AP logs were normal with no issues reported.

Unlike Roon, the Sonos app saw all my Sonos devices without issue (7:49 local time) [edit] and to confirm, they were still not seen by roon. They were there but not recognized by roon.

sudo systemctl restart roonserver and the devices reappeared and play normally (07:53 local time) with roon remotes.