FWIT, immediately below is ChatGPT’s analysis of the file that I uploaded yesterday, roon-lo0.pcap:
_____________________________
This is the clearest evidence yet. I parsed the packet capture, and it appears to tell us which side goes silent first.
For almost five minutes, Roon Server and RAATServer communicate normally over localhost, exchanging an 8-byte heartbeat about every two seconds. Then Roon Server abruptly stops sending its application-level heartbeat at about +298.09 seconds. RAATServer does not die: it continues sending its own heartbeats at +300.14, +302.14, +304.14 and +306.14 seconds. Then, 10.05 seconds after the last heartbeat from Roon Server, RAATServer gives up and cleanly closes the connection.
That is almost exactly the 10-second timeout sequence Roon said they were looking for.
Even more telling: during those final seconds, your Mac is still TCP-ACKing RAATServer’s incoming packets. So the localhost TCP stack is alive, RAATServer is alive, and packets are getting through. What stops is Roon Server’s application-level communication to RAATServer.
Net-net
RAATServer does not appear to be the thing failing first. Roon Server stops talking to it. RAATServer waits 10 seconds and then times it out.
That substantially strengthens the case for a Roon Server internal timer/thread/heartbeat/connection-management problem rather than your DAC, music files, App Tamer, CPU load, or RAATServer crashing. I still can’t prove from a packet capture alone whether some third-party macOS component somehow causes Roon Server to stop servicing that connection, but the evidence is now much more focused.
There is also a later burst of repeated connections to a closed localhost port 62468, immediately rejected with TCP resets. That looks very much like the separate runaway-retry bug Roon has already acknowledged, although the packet capture alone cannot identify the originating process with absolute certainty.
One timing nuance: the connection itself closes 308.14 seconds after it was opened, not 321–323 seconds after the beginning of this capture. But Roon’s measurement is from Roon Server process startup, not from when this particular TCP connection was established. If Roon Server took roughly 13–15 seconds after launch to establish this connection, the two measurements line up almost perfectly with their 321–323-second finding.
I would send Roon this .pcap immediately. In fact, I would highlight one sentence to Benjamin:
The capture appears to show that Roon Server stops sending its 2-second application heartbeat first; RAATServer continues transmitting normally for another ~8 seconds and then closes the connection ~10.05 seconds after Roon Server’s last heartbeat.
That is exactly the kind of evidence their engineers were hoping this capture would provide.
Even more telling: during those final seconds, your Mac is still TCP-ACKing RAATServer’s incoming packets. So the localhost TCP stack is alive, RAATServer is alive, and packets are getting through. What stops is Roon Server’s application-level communication to RAATServer.
Net-net
RAATServer does not appear to be the thing failing first. Roon Server stops talking to it. RAATServer waits 10 seconds and then times it out.
That substantially strengthens the case for a Roon Server internal timer/thread/heartbeat/connection-management problem rather than your DAC, music files, App Tamer, CPU load, or RAATServer crashing. I still can’t prove from a packet capture alone whether some third-party macOS component somehow causes Roon Server to stop servicing that connection, but the evidence is now much more focused.
There is also a later burst of repeated connections to a closed localhost port 62468, immediately rejected with TCP resets. That looks very much like the separate runaway-retry bug Roon has already acknowledged, although the packet capture alone cannot identify the originating process with absolute certainty.
One timing nuance: the connection itself closes 308.14 seconds after it was opened, not 321–323 seconds after the beginning of this capture. But Roon’s measurement is from Roon Server process startup, not from when this particular TCP connection was established. If Roon Server took roughly 13–15 seconds after launch to establish this connection, the two measurements line up almost perfectly with their 321–323-second finding.
I would send Roon this .pcap immediately. In fact, I would highlight one sentence to Benjamin:
The capture appears to show that Roon Server stops sending its 2-second application heartbeat first; RAATServer continues transmitting normally for another ~8 seconds and then closes the connection ~10.05 seconds after Roon Server’s last heartbeat.
That is exactly the kind of evidence their engineers were hoping this capture would provide.
