Playback significantly less reliable recently: more frequent "An audio file is loading slowly" errors

Recently (and the most recent significant change here is just the Roon update to v276), I’ve gotten infuriatingly many of those “Roon: An audio file is loading slowly” messages.

I can’t prove cause, but they hadn’t been happening until recently (also recent: the move to Roon v276).

I’ve also noticed that they seem more common when multiple zones are synchronized, and seem easy to trigger if I click around in the timeline for MP3 files like podcasts, especially if I try to jump back a bit…

…but I’ve recently also had it occur just when a new track at a different (especially high) sample rate comes up in a queue and Roon is trying to get multiple zones synchronized. I’ve heard a couple of zones start playing, then the whole thing fails and Roon skips to the next track.

Especially infuriating: Roon seems to think it’s being clever by removing the affected track from the queue history, so hitting the Previous button to try to get Roon to try again backs up into a neverland rather than going back to the damned track I want to force it to try again. Generally if tried again, these tracks will eventually work fine (although I generally won’t get more than one try at a timeline skip before the track is abandoned again - so I have to guess correctly about where the podcast needs to be resumed or I’ll have to reload the track for another try).

Generally if I stop RoonServer and restart, playback works fine right after - but I don’t know if that’s a coincidence or a useful observation. Could there be a memory leak in RoonServer? Could you have reduced the time allowed for zone synchronization to complete, thereby causing early timeouts which wouldn’t have happened had the software been more patient?

This is with a hardwired gigabit network to zones, and music storage local to the Linux RoonServer machine.

Lemme know if there’s anything I should be looking for in the logs to pass you.

1 Like

Flagging @support.

Thank you for the feedback @Jeffrey_Moore, we appreciate you sharing your observations with us.

Moving forward, may I very kindly ask you to please provide me with the following information:

  • Based on your post it seems like the reported issue is more pronounced when using multiple group zones. During your troubleshooting have you tried using just a single zone? I am just curious as to what the stability of a single zone is like in comparison to a grouped number of zones.

  • During your troubleshooting have you tested with a device mounted either directly to your Roon core machine or a roon remote (i.e a desktop or laptop computer)? If so what was the experience like.

  • If you can readily reproduce this behavior, may I kindly ask you to do so 3 times and note the time of day in which the errors are observed. Once I have this information I will then enabled diagnostics on your account so our techs can try to get a better sense as to what is causing this behavior in your setup.

-Eric

Thanks for checking in!

I don’t recall having seen this happen with a single zone; now that I’m paying particular attention, I’ll notice and report if I see the issue in that circumstance.

This has all happened when using dedicated zone players, three flavors of Sonore *Rendu. These have all been solid in single- and multiple- zone groups until recently.

I don’t routinely even keep an audio output device connected to most of the desktop machines running Roon -
I use those as controllers but practically never as players - but I can try fiddling with configurations like that I guess.

In-depth stress testing and reporting back failure times may need to wait as long as until the weekend, given my schedule; sorry.

@Jeffrey_Moore ----- Thanks for the follow up and taking the time to answer my questions, very appreciated!

As I am sure you are aware, the goal is to try to get a sense of “where” the issue is occurring and what “actions” cause the behavior. No worries on the wait, I am going to enable diagnostics on your account so we can start looking further into this behavior and once you’ve got some “failure times” I can re-enable so we have those time frames in a fresh set of logs :thumbsup:

I will be on the look out for your feedback Jeffery, thanks again!
-Eric

Okay, @Eric - I got the chance to torture the Roon server with some of the situations which now seem to trip it up (multiple synchronized zones, possibly exacerbated by having to read from an ffmpeg process decoding a lossy format and/or skipping around in a timeline).

First up: things got confused playing an AAC Internet radio stream into multiple synchronized zones:

It’s possible that there was actually a problem with the source stream right then (while I don’t believe there’s any plausible chance the play problems from locally-stored files involve any slowness reading those files from disk), but this Internet Radio symptom seems really similar to the issue reported in this thread’s original post: Roon gets befuddled trying to get multiple playback zones synchronized, then emits an error message implicating the source.

I believe what I did just before this happened was to change which zones were in the synchronization group while a stream was playing.

The above happened just before 2017-12-07 15:45:52.

A little later, I got the chance to try a few jumping-around-a-podcast torture tests. I got it to blow a couple of times - just before 2017-12-07 17:47:55:

55

and just before 2017-12-07 17:49:16.

In both of the last two cases, there were 6 or 7 zones synchronized, and I was clicking around in a 1-hour MP3 file (which I think was 128k CBR).

I also had this issue with locally stored music, but rebooting my ROCK on NUC has fixed it so far. It had been running for 9+ days.

Thanks for the follow up @Jeffrey_Moore! I appreciate you providing me with time frames as to when the issue was occurring :thumbsup:

Moving forward, as mentioned, I am going to be enabling diagnostics on your account once more so we can try to get a sense as to what may have happened during the mentioned time frames. Once I have some feedback from our techs on your issue I will be sure to provide you an update in a timely manor.

-Eric

1 Like

Hi @Jeffrey_Moore ----- I wanted to reach out to you because I noticed an issue today with the received diagnostics report.

I was preparing your ticket and while combing through the logs attached to the diagnostics report I noticed that some log files had been missing. This indicates to me that an issue may have occurred during the upload to our servers. I want to make sure that your issue is addressed in a timely manor and also that our tech team have the logs from the time frames mentioned in your previous post.

In light of the above, I would very kindly like to ask you to please upload us a set of logs via the instructions found here.

Many thanks!
-Eric

@Eric - I’ll make a note to do that when I get back home.

1 Like

@Eric - uploaded logs. Details in direct mail to you.

Note that the seizing-up issue happened again quite recently, should be included in logs just sent. The time was:

2017-12-17 17.46.32

A track came up in the queue, and Roon apparently just gave up on getting the numerous synchronized zones lined up and skipped to the next track with the “An audio file is loading slowly” error.

Oh, an additional data point I don’t think I mentioned explicitly: the zones don’t all have the default Clock Master Priority, they each have a priority chosen based on how important I think maximum fidelity at that particular player is - so, the lowest number (highest priority) for the one native MQA DAC I have, then increasing numbers as the systems being fed get less fussy.

So I dunno, maybe the combination of a bunch of zones with all their faster/slower-funning clocks plus the additional strain of having to wrench synchronization fill into a priority order other than what might have been chosen just from the way the clocks line up is what’s busting a gasket in sync.

Thank you touching me @Jeffrey_Moore, the update is appreciated!

Confirming that the logs have been downloaded and passed over to our techs for evaluation. Once my report is passed back, I will be sure to share the team’s thought/findings with you in a timely manor.

-Eric

1 Like

Hi @Jeffrey_Moore ----- While I am still waiting on some feedback from the tech team I wanted to touch base and see if there has been any changes in behavior, in regard to this issue you’ve reported to us since the latest update(s). Looking forward to your feedback!

All the best to you and your family this holiday season!
-Eric

Hey, @Eric - I was actually planning to follow up to mention that I’ve been seeing the same sort of thing still happening in 1.4 / build 294 and ask if you’ll need me to collect some further failure timestamps with the current build.

Good holiday wishes right back at you, your family and the whole Roon team!

@Jeffrey_Moore if you could, that’d be great as I am almost certain our techs are going to want to see the issue occurring with the latest build.

Many thanks!
-Eric

Okay, will do sometime over the weekend (although I hope you busy bees will be taking some time off!)

But I believe they can trigger these no problem - just synchronize 5-6 networked players with an assortment of nonstandard zone priorities and forced upsampling DSP on a couple of them, and just play streams and long MP3s and files of varying sample rates and skip around in timelines.

And at least with the later v1.3 builds, there seemed to be a correlation between the Roon server’s fragility and how long it had been running. I don’t have enough data to really be sure of this, though.

But I didn’t really even have to torture the system to get it to pop a gasket earlier today - playing a straight FLAC with only 3 zones synchronized blew it up a few times in a row.

Hi @Eric,

I just wanted to let you know that I had the same problem today, 23 DEC. at around 15:15 CET. During the playback we had some dropouts in a track. Roon started the next track and we received the message „an audio file is loading slowly. This may indicate a performance or hardware problem.“

Please note that we are running only a single zone with rock running on a NUC7i5.

Kind regards and Merry Christmas,
Kay

Hey, @Eric - sorry for the delay; I have two recent occurrence times from today to report:

2017-12-30 at 14:51:15

2017-12-30 at 15:55:03

The Core is RoonServer v1.4 (build 294) on Linux.

Do you need anything further from me to be able to look into those, or do you have enough info to be able to reach out and grab those logs?

UPDATE 2017-12-31: yes, grouped play is seriously fragile now. Another instance to report, at 2017-12-31 16:24 plus or minus a minute. During play from a playlist, no manual skipping around or fussing with groups on my part, Roon failed to get at least one, maybe two tracks started and synced, so skipped ahead. I could hear the first second or fraction thereof begin to play in a nearby zone, then silence and it was on to trying the next track.

Hi @Jeffrey_Moore ----- Thank you for the update and providing the requested feedback, both are very appreciated.

Moving forward, upon returning to the office after the holiday I saw your update and enabled diagnostics on your account. It is strange, I am running into the same behavior we had encountered previously were I am getting an incomplete report :thinking::thinking: As before would it be possible for you to manually send me over a set of your Roon logs using the same instructions?

Many thanks!
-Eric

Hi @Kay_Levermann ---- Thank you for chiming in here to share you observations. The insight is appreciated!

In regard to this error message (i.e" an audio file is loading slowly. This may indicate a performance or hardware problem") how often are you seeing it and are you able to trigger this error message reliable?

-Eric