· None of the above quite fits
· None of these quite match
· Streaming pauses (short buffer?) since 2.58 build 1608
· Ubiquiti Unifi
USG-Pro-4 router and US-24-PoE switch
Hello @James_Fitzell ,
Thanks for reaching out and letting us know. Does the issue impact multiple zones, or just one audio zone in particuar? Can you please let us know the exact local time + date + track when you next observe the issue? We’ll enable diagnostics to see if there are any relevent error logs.
Hi Noris,
It’s impacting multiple zones.
It happened a lot to me yesterday on Study (a LAN connected Ropieee endpoint with an IQ Audio AMP+) and today it just happened to me twice on Lounge (a LAN connected Rotel S14). The time of these latest events was 3 Feb 26 between 11:25-27am (AEST - Sydney time).
For me it’s only been occurring with transitions to/from short tracks (but I’ve never had issues with short tracks before this release). The album today was A State of Trance Year Mix 2025 (Mixed by Armin van Buuren) coming from Tidal, and the tracks were Track 7 - Deep Shadow (Mixed) and Track 9 - Turning (Mixed).
Cheers,
James
One update. Yesterday I had one of the pauses last so long that the music actually stopped playing, but with that one exception all of the issues have been just pauses in the stream and after a few seconds the music continues.
Thanks for sharing the timestamp @James_Fitzell!
From a fresh diagnostic report, we can see the following trace around the time you’ve shared:
Trace: [prebuffer] short read: 0 / 8820 fill=439237 It indicates that when Roon tried to pull the next chunk of audio data from the source (TIDAL FLAC) to fill the buffer, it received nothing back.
If the Raspberry Pi (IQaudIODAC) is on Wi-Fi, try connecting it via Ethernet. High-resolution FLAC is sensitive to the “jitter” and micro-drops common in Wi-Fi.
I’d also review your device buffer settings. In Roon, go to Settings > Audio, find your IQaudIODAC, click the gear icon for Device Setup, and look for “Buffer Size.” Increasing this can provide a larger safety net for network fluctuations.
Let me know how the above goes, thank you! 
Hi @benjamin,
You’ll note that the device causing the error at the time I flagged for review was a Rotel S14 connected by LAN (not a Raspberry Pi and not connected by Wifi). Every single one of my devices is LAN connected, and they have all been having problems since the latest Roon release. I absolutely agree it’s related to the buffer running out, however this has never happened with these albums prior to 2.58 build 1608.
My internet connection is rock solid (and fast) and does not fluctuate, the only change has been the Roon update. Why should I need to manually update 13 zones (including 5 Roon Ready hardware devices) with increased buffer when the issue is clearly 2.58 build 1608?
Cheers,
James
Hello @James_Fitzell,
Thank you for your patience. While investigating the data from your Roon Server, which we pulled via diagnostic mode, we identified a critical pattern in the system logs that explains the “short read” symptoms you’re experiencing.
In the diagnostic reports, we observed a recurring system-level error: System.Net.Sockets.SocketException (104): Connection reset by peer.
Feb 2 09:31:49 (none) user.notice ntpd/run: reply from 2610:20:6f97:97::6: offset -0.000347 delay 0.187459, next query 1531s
Feb 2 09:36:01 (none) user.notice roonserver/run: System.Net.Sockets.SocketException (104): Connection reset by peer
Feb 2 09:36:01 (none) user.notice roonserver/run: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
Feb 2 09:36:01 (none) user.notice roonserver/run: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)
Feb 2 09:36:01 (none) user.notice roonserver/run: at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
Feb 2 09:36:01 (none) user.notice roonserver/run: --- End of stack trace from previous location ---
Since this issue is occurring across multiple LAN-connected zones (including your Rotel S14 and RoPieee), it suggests a systemic communication problem rather than a software bug in a specific endpoint. We recommend checking the following:
Connection reset packets.The diagnostic data confirms that the core of the problem is a persistent drop in the network connection at the system level. Please let us know if adjusting these network/physical parameters stabilizes the connection.
Thanks @vadim,
I don’t understand why this has only started occurring since the latest roon update, but you’ve certainly given me some points to investigate.
Based on your tip I’ve now done some netcaps and I see that I am getting these resets on internet traffic (local streaming of FLAC files from my NAS over CIFS has double the traffic and no resets at all). That being said, in every case I saw the TCP RST demonstrates Roon responding to a FIN/ACK packet from Tidal (which is an accepted closure of the conversation and not an error) so these would seem to be expected as the stream finishes and starts the next stream and still don’t explain the pauses?
Thanks,
James
Hello @James_Fitzell,
Thank you for that detailed observation from your network captures. It is an excellent point of investigation.
The FIN/ACK followed by a TCP RST (Reset) that you’re seeing can indeed be a normal part of how a streaming session closes, but the frequency and context of these resets in your system logs suggest they may be happening prematurely or unexpectedly during active playback, rather than just at the natural end of a track.
When we analyzed your Roon Server’s logs via diagnostic mode, we looked specifically for the System.Net.Sockets.SocketException (104): Connection reset by peer error.
FIN/ACK is a graceful close, a SocketException (104) at the application layer (Roon) indicates that the underlying connection was severed while Roon was still expecting to receive data. This immediately empties the playback buffer, resulting in the “short read” traces Benjamin identified earlier.If this were a core issue with build 1608 itself, we would expect to see a significant volume of similar reports from across our user base. Since we haven’t made any changes to this specific area of the code in this release, and yours is an isolated case of this specific socket exception, it strongly points toward a unique interaction in network behavior.
Additionally, since the error is specific to external connections, it could be due to incorrect DNS settings or issues on the side of the content delivery nodes (CDN). If your ISP’s DNS server is unstable or returns an outdated IP address for the TIDAL server, this could lead to dropped TCP sessions. We recommend trying to temporarily change the DNS servers in your USG-Pro-4 router settings to public ones (for example, Cloudflare DNS: 1.1.1.1 and 1.0.0.1 or Google DNS: 8.8.8.8). This will help rule out the possibility that the connection is being dropped due to routing errors at the ISP level.
Your observation that local CIFS streaming is unaffected is a key clue. It confirms that your internal network’s basic switching and throughput are healthy. However, it highlights that the issue is specific to long-lived WAN (Internet) connections to TIDAL’s servers.
Would you kindly confirm whether you have you followd the recommendations from my previous reply?
Hi @vadim, relevant responses in-line below.
Would you kindly confirm whether you have you followd the recommendations from my previous reply?
Even a high-quality network can suffer from a failing Ethernet cable or a “sticky” port on a switch.
Try swapping the Ethernet cable for the Roon Server or moving it to a different port on your US-24-PoE switch. A faulty physical connection often triggers theseConnection resetpackets.Your USG-Pro-4 has powerful security features that can sometimes interfere with high-bandwidth, long-lived streams. Check if Threat Management (IDS/IPS) is enabled. If so, try disabling it temporarily to see if the socket exceptions stop.
Given you are using a UniFi switch, ensure that Flow Control is enabled in the Unifi Controller settings. This helps manage data bursts and prevents the switch from dropping packets that could lead to a TCP reset.
Yes I’ve confirmed that IDS/IPS is disabled (2) and Flow Control is enabled (3). Re cables (1), I am doing this today, and also swapping the cable to the modem since it seems like the internet connection is at least partially implicated.
This specific exception occurred 24 times in the logs between February 2nd and February 7th, coinciding exactly with the timestamps of the playback pauses you reported.
The albums causing the issues have very short tracks (as low as 30 seconds) so 24 times would seem quite low if it’s purely occurring at the end of each track. In the testing I referred to above I had it occur 10 times over 8 tracks so that fact that you’ve seen it “only” 24 times implies that the events don’t necessarily correlate to the end of each track.
Your observation that local CIFS streaming is unaffected is a key clue. It confirms that your internal network’s basic switching and throughput are healthy. However, it highlights that the issue is specific to long-lived WAN (Internet) connections to TIDAL’s servers.
I agree this is a key clue and indicates that the general network is healthy, although I’ve realised that the difference between the two is that Roon is “pulling” the flac files (in this case a single 2hr flac file of the same mixed album) and then doing the streaming itself, while for TIDAL it’s receiving a stream so it’s not surprising that the buffering and network layer looks very different. Unfortunately I can’t think of a way to test streaming to Roon “locally”.
I’ll update later today/weekend once I’ve changed the cables and done some more captures.
Hi @vadim,
Another quick update. I changed cables and restarted the router (and Roon).
Over a 1hr 40 minute period I listened to one of the albums I’ve had problems with (ASOT Year Mix 2024). During this capture I had no pauses in music, but I still saw 108 TCP RST from Roon to Tidal. According to the packet capture every RST indicated successful completion of the TCP session, however it’s hard to correlate whether these perfectly match the track changes purely from the network side. The album has 113 tracks (over the full 2hrs, not 1:40) so it’s generally consistent but not a 1:1 match.
I’ll continue monitoring, on a positive note I haven’t had any pauses since the changes. 
That is great news @James_Fitzell, let us know how things perform over the weekend. 
Unfortunately the issue is still occurring.
I’ve made several more changes as part of the investigation:
Still intermittent short pauses (~1 second or so) at many track changes on albums with short tracks. I haven’t heard any problems on other albums, it’s only audible on the really quick/short track changes (the sorter the track the more likely the next track will have a brief pause as if it hasn’t buffered yet).
No other noticeable performance issues on the network… local playback is fine (although I don’t have any local albums with such short tracks) and all my non-Roon streaming is also fine (we’ve had the Olympics going for hours every day. Online gaming also fine and implies no latency or packet loss issues (ditto internet tests I ran after the switch of ISP).
I’ll take some more packet captures and update, but wanted to make sure I noted the issue was continuing after all those changes (and the previous cabling changes discussed with Vadim).
And of course it hasn’t happened since my last message (which is good I guess 
).
Will update in a few days.
Sounds good @James_Fitzell, thank you for the continued updates.
I think we can safely close this. Whatever the exact root cause I haven’t had any pauses in a week despite repeatedly listening to the “problem albums”. Thanks for your assistance!
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.