Audio files loading slowly and constantly being dropped since last core update

Roon Setup

Roon Core: Small Green Computer Sonic Transporter I5 (gen3) (2017)

Music Files: Synology NAS DS 1019+

Router: TPLVX220G2VDD

Extender: tp-link AC1750 Mesh Wi=Fi Extender

Players: BlueSound Flex; PulseMini

Bluesound Node connected to NAD M51, NAD C 275BEE and JAMO C 809

Number of Tracks in Library

196325 Tracks

Description of Issue

Four months ago I move cities, and in the process went from having the perfect Roon setup, to one where Roon has been consistently problematic. A lot of the issues were caused by the new internet provider and have been resolved (ie I can now use ARC again…). Similarly, the router is different, and I needed to get a wifi extender. Once done, less problems.

However, with the most recent Roon updates to my Core, the situation has become much worse. The main problem has been accompanied by the error message, “An audio file is loading slowly, this may indicate a performance or hardware problem.” The player would drop the file. Sometimes it would also drop the next several files in the queue. The incidence of this happening was down to perhaps two or three times in the evening. (Still way way too often).

But now - as I type - Roon is dropping almost every second track. It seemed to become radically worse after the core update of several days ago. I have subsequently also updated the Bluos software in the players, which had previously made a difference. But this has not helped, on this occasion.

SO, what does one have to do to increase the speed with which audio files load, so they are not constantly being dropped by the players? And why has this become a problem now?

(Btw, it doesn’t seem to matter the size of files, format or sample rate.)

Roon is the best thing since sliced bread, but when it constantly mangles the music it really is not good for my blood pressure or equanimity, lol. (And there it goes again, dropping another stream of files…).

Hard to tell exactly but it looks like you are mostly WiFi usage.
Which can be perfect as you found previously.
However it can also be a total trainwreck, as it now appears to be.
So many external events can affect WiFi that are usually out of your control.
But…is your Roon Core connection by WiFi or Ethernet, can’t really tell.

The key point is that the change in behaviour followed DIRECTLY from the update on the Roon Core. That update has made the whole system incredibly unstable. Nothing else changed. The core runs on the Sonic transporter and is hardwired to the router and the NAS. All players are wifi connected.

The Sonic Transporter has been known to give issues previously, I know this from experience.
Usually to remedy I uninstalled Roon from it, rebooted it and then reinstalled Roon.
Obviously make sure you have good up to date backups before trying this .
This usually occurred at an update of Roon.

1 Like

Thanks for this advice! I have not actually yet had to take this step, but preparing to do this did lead me to discovering what seemed to be the problem.

What I discovered was that the software on the Sonic Transporter itself needed to be updated. Somewhere I read that despite the fact that the dashboard tells you that you have 2.8 running, and that 2.8 is the latest version, in fact what it means is that 2.8 is the latest MAIN version, and does not list how many minor updates there have been to 2.8 or whether you have them all. Turns out there have been minor updates to 2.8 and I did not have them. So when I pressed the update button just for the heck of it, there was what turned out to be significant updating.

Then there was panic: for a significant period after the update, none of the players could find the Roon server; it was not there to be logged in to from anywhere. And yet the Sonic Transporter web interface had it there, all ticketyboo, apparently, waiting to be used.

The solution to everything is a good whisky - and it turns out that once I had had a dram, Roon was all back and ready to go. Evidently the Sonic just needed some time to process its issues… (don’t we all!!) It has been running perfectly smoothly since. Not a single dropped or slowly loading file.

So, thanks for the advice, and helping me find my way to the solution!

Problem solved!!

1 Like

Glad to hear you are now able to enjoy music again.
And yes that event of not being fully updated despite it saying so does ring a bell, nice find though.

1 Like
Full form submission

What’s happening?

I'm having trouble playing music




But the saga does not stop there.

For about a week, perhaps, the music was sweet and uninterrupted. But then, all the dropping out started happening again, along with the file loading slowly errors, etc etc. I rebooted everything, checked that everything was updated, cleared cahces, etc etc. All to no avail.

Two matters arise: one is that as I have been trawling through the information about what might be the problem, I have discovered that the purchase of a wifi extender was apparently a mistake. So now I am considering replacing it with a mesh solution. I would appreciate any more specific advice around this (ie are their more or less recommended types?)

But, my review (as a complete ignoramus) of the debug logs for my sonic transporter suggest that there is a more significant problem than just wifi congestion at play.

I use my Ipad as my main remote, and sometimes I also play music to my ipad (although not often). So it was enabled as an end point. I noticed that when reviewing the log of faulty playback to my lounge room system, it often mentioned sending the audio to the ipad. Which it wasn’t supposed to be doing, and as far as I could tell wasn’t actually doing, as the ipad was not playing. In the hope that this would fix the problem is dis-abled the ipad – but no broader positive result emerged.

Reviewing the log for one episode of multiple track playback failures this evening, I notice repeated language such as:


02/18 19:39:53 Warn: [Lounge Room] [zoneplayer/raat] failed to sync sender clock to endpointBluesound NODE 2: Sooloos.Broker.Transport.ClockSyncResult
02/18 19:39:53 Warn: [Lounge Room] [zoneplayer/raat] failed to sync clocks with any endpoints..giving up
02/18 19:39:53 Info: [audio/env] [zoneplayer -> stream] All streams were disposed
02/18 19:39:53 Info: [audio/env] [zoneplayer -> stream -> endpoint] All streams were disposed
02/18 19:39:54 Info: sleep 200ms after flush
02/18 19:39:54 Warn: [zone Lounge Room] Track Stopped Due to Error
02/18 19:39:54 Info: [zone Lounge Room] OnPlayFeedback StoppedEndOfMediaUnnatural


In actual audio world, this was accompanied by a track failing at about 2 minutes in, followed by Roon skipping past a series of queued tracks, trying to play one or two of them, failing, and then stopping completely. This kind of behaviour has been happening a lot. Although, weirdly, not consistently. Being a Sunday, and over 40 degrees Celsius outside today, I was at home and indoors all day, and managed to get in about 4 or 5 hours of relatively uninterrupted listening – before this behaviour set in. For some reason it does seem to come in waves like this! It is notable that the track almost always fails at about 2 and a half minutes.

[Side note: I don’t have any problems with playback using ARC!!]

Any advice would be most welcome!!

Apologies about the system failure with your last support request - I’ve deleted the topic, leaving this one for the Support team to deal with.

1 Like

Hi @ajl,

I’ve reopened your older topic, merged your new topic into it and removed the duplicate info as it’s all in one place once more.

Thanks Carl for reorganising the post. Any idea how long it will be before support arrives from the Roon crew? (It seems that the @ support flag waving device doesn’t function anymore either?) I like the look of the new help system, but have no idea of actual timelines for direct support atm.

Hi again @ajl,
No, I have no idea either. All I can say is when it reaches the top of the @support team’s queue but I have no insight on that queue.

Interestingly the dropping of files problem has moderated somewhat since the new software update that hit my devices a couple of days ago. Not fixed, but not as bad. At least I can listen without a blood pressure problem!! :wink:

@connor any chance you can help with this please. Or one of your colleagues? As I write I am getting multiple drop outs. It’s been a week and no response from the team. Or perhaps @benjamin or @noris ??

Hi @ajl,

We’re sorry to hear that you’re encountering dropouts and thank you for your patience.

Here’s what we can tell from diagnostics and from reviewing this report:

  1. BlueSound is investigating an issue with grouped Zones in Roon affecting any BluOS-capable devices. The “unnatural” dropouts you’re seeing in logs are the final symptom after accumulated sync errors between these devices. If you ever encounter a symptom of grouped devices losing sync before a dropout, then you’re bumping up against this known issue. We’re working with their team to identify and resolve the issue.

However, when you’re playing to individual BlueSound Zones or any other endpoint, the dropouts are due to accumulated packet loss in the WiFi connection, as explained below.

  1. We’ve taken a diagnostic sample of RAATServer’s activity as reported to our servers once we enabled diagnostic mode. During the period you’ve reported, the TCP stream to your endpoints is losing integrity. Devices are reporting sample dropouts repeatedly while streaming even to an individual networked endpoint. Your Remotes are similarly dropping in and out of connection to your RoonServer machine. In either case, after enough of these samples have gone missing, RoonServer and RAATServer will automatically kill the TCP stream due to data loss. This will manifest as playback stopping, or the Remote disconnecting entirely.

I can confirm in logs that this is occurring with most of the endpoints described in your post. The culprit here is unfortunately tricky. Your SonicTransporter’s network adapter, the mesh topology, and your router’s multicast settings will all play a role in negotiating and directing traffic appropriately.

I would start by minimizing the setup until you find an endpoint setup that can reliably play a high-resolution file without dropouts. Try hardwiring one of the network endpoints via ethernet directly to your RoonServer machine. If you can play successfully, then try hardwiring it directly to the extender or mesh node instead. Slowly build back in components of the network until you’ve identified the weak point.

Thank you again and hopefully this has helped provide some insight.

Hi Connor - many thanks for this reply and for the examination of the logs and etc. It is at any rate useful to know that the problem is somewhere in the network. I will do as you suggest and try to identify the weak point. I have already run a temporary ethernet cable to my preferred listening endpoint which has made life much more enjoyable (and works like a charm). Now to find where the other weak points are.

Keep up the good work - Roon is fabulous and I look forward to seeing how the Harman acquisition helps in further development of the product and your team!!

Thanks again,
Anthony

Hi @ajl,

I wanted to ping this thread before it auto-closed in case we can provide any more assistance. Were you able to identify any WiFi interference points in your network setup?

Thanks @connor !
What I’ve done is connected my main listening post to the router with Ethernet cable. This is a temporary fix, with the cable strung along outside and going in and out of windows, lol. But it seems to have made the whole system much more functional. The two remaining wifi endpoints hardly ever drop files now, and the wired one works like a charm. Being both busy with work and then ill with Covid I’ve not had a chance to actually go hunting for the faults beyond this. Since the temp fix works a charm I might just leave it as it is…. Thanks again!