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

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

Another incident to report, @Eric - on this past Sunday the 7th between about 12:07 and 12:08, I spent some time fighting with Roon trying to get it to play an internet radio stream to six zones. I knew I was pushing my luck before I even tried. After multiple failures, I dropped to five zones, and after I think only one further failure, that took.

I can send logs again if they’d be helpful and you still can’t reach in and pull them.

FYI, Roon playback continues to be extremely fragile when multiple zones are synchronized. I wince a little whenever I add a playback room on the fly, or prepare to start an internet radio stream playing to a group of zones, preparing for the not inevitable but pretty common failure, manual play restart, and possible repeat of same.

This was bulletproof before build 276. So it really seems like you guys made some unexpectedly substantive change to the protocol around then, or tightened a timeout whose previous value allowed synchronization to work reliably. I haven’t been making an endless stream of followup trouble reports, but please know that my silence hasn’t meant that the problem went away.

Thanks.

Thanks for letting us know @Jeffrey_Moore – we’re going to look into this.

Is this worse with any zones or devices specifically? Or does linking seem to affect everything the same way? The more specific you can be in your testing, the more crisp we can get this report before it goes under the microscope with the dev team.

Appreciate your patience here Jeffrey!

Thanks, @mike!

I haven’t seen a consistent pattern of particular zones making this fail more often, even though a couple of zones are doing forced upsampling, which I’d theorized might increase fragility.

Likelihood of failure seems to correlate most closely with how many zones are synchronized.

Note that there’s one thing about my setup which may not be getting a lot of testing coverage at Roon Central: I have not left the Zone Grouping / Clock Master Priority values for these zones at the default setting. I have distinct priorities set for all the zones, starting with the lowest number / highest priority value for the currently only zone in the house which strictly requires a bitperfect stream (because it has an MQA DAC), then counting up from there in decreasing order of how resolving each system is. So… I can imagine that there might be a natural order Roon would want to use when left to its own devices to order master and padded slaves based on the relative run rates of all the zones’ clocks, and my priorities may be forcing the server to wrench things into a pessimal order. And… the Roon devices in our house have bred like bunnies, so sometimes I’m trying to sync as many as six zones.

The failures tend to happen most often as play starts (or re-starts itself after an on-the-fly change in the synchronization group). Once play gets going and synchronized, it’s far less likely for this problem to occur. I’ve also seen failures at the transition between two on-disk local tracks (perhaps only when there’s a resultant change in sampling rate), but I think this case is more rare than failure when starting from a dead stop.

I don’t have enough data to be sure this is a real correlation, but I have a feeling that this problem is most likely to occur when playing an Internet Radio stream or an MP3 file like a podcast and least likely to occur when playing a track stored on the local disk in a lossless format natively understood by the Roon server.

Note that when the failure has occurred, fairly often I’ve heard sound start to play from one or two zones in earshot but never get as far as sound coming out of at least one other of the zones. Perhaps this offers a clue about what’s going on during that awkward startup phase.

Oh, as for the zone hardware involved: it’s all basically the same platform - all Sonore devices (a couple of ultraRendus, three microRendus, one Signature Rendu SE) although feeding a variety of USB DAC devices which I assume are the clock masters. I can list those if actually of interest.

UPDATE 2018-01-20: Thinking maybe I’ve just been asking for trouble with my array of Clock Master Priority values, I set all of them to Default, then boldly put six zones in a group and clicked play on a podcast. Nope, got the error and a skipped track a couple of times in a row before that track would consent to play into the group. So… maybe Clock Master Priority values aren’t a spacial insight into this issue after all.

I see some good news in the latest release notes: Roon 1.4 (Build 298) Is Live!:

  • Zone Grouping stability and syncing fixes

Sounds like the devs have a fix for this problem in the latest release. I just tried a grouping setup which had been flaky in the previous build a few times in the new Build 298, and so far I haven’t been able to get grouped Roon play to fail the way it had been. I’ll sure chime in if I see a suspicious failure in the future, but I’m initially quite hopeful that this bug has been squashed.

2 Likes

Unfortunately the latest release did not solve the syncing issues with BlueSound devices. Guess it’s up to BS now to update as well.

Update 2018-02-02: Hey, @mike and @Eric - I have actually seen this problem recur, but only twice so far in the past week-and-a-half, which is way way better than the previous multiple times a day. So… really no longer something seriously reducing quality-of-life as a Roon user and now easily ignored; but if the fix involved changing some internal timings, a tiny additional nudge further in whatever direction was involved in the Build 298 fix might not hurt.

Another update (2018-02-23): Sadly, this problem is still happening, and sometimes pretty frequently - I had to restart the play of one track 3-4 times in a row this weekend before it stabilized and played fine from there on.

I still think it’s less bad than before the recent software update, and (while I’ve been hesitant to claim this without more data), I have this feeling that these synchronization misbehaviors are more frequent after RoonServer has been running for awhile - note that a few more weeks of the server being up have elapsed since the last report.

Here, @mike and @Eric - in case there’s a chance that a memory leak or some other source of growth in the size of RoonServer’s memory footprint over time is correlated with increased fragility - here are a couple of lines from RoonServer_log.txt at different times.

This is after RoonServer had been running for a couple of weeks (I believe steadily since Build 300 was installed 17 days ago):

…and this is after a restart of RoonServer (after just enough time to allow the initial rescans to finish):

Dunno if this actually has anything to do with the fragility I’m still seeing with grouped zones, or if it’s a red herring.

A post was split to a new topic: Single zone - “An audio file loading slowly…”

@Jeffrey_Moore ---- Thank you for the feedback and my apologies for the response here. Hope all has been well!

I wanted to check in and see if you have made any new observations in regard to the above. These types of issues are often very tedious to troubleshoot because it requires a fair amount of observation reporting from the user. We need to know exactly how you are using the application on a daily basis, which can take time. The more info you can get us the better the the likelihood is of understanding the issue.

-Eric

Nothing really new to report. On weekdays, I usually play my getting-ready-for-work Internet Radio stream (WFMU, natch) to three zones (bedroom, bathroom, kitchen) and that usually works fine.

On weekends, we often want to listen to the week’s collected podcasts, and have them playing basically everywhere so we can wander freely about the house without getting out of earshot. This can involve up to six zones, and can lead to the frustrations described here.

Hi @Jeffrey_Moore ----- Thank you for you for the feedback and more importantly, thank you for your patience while I have been coordinating with our tech team in addressing this behavior you are experiencing.

As mentioned in my previous, trying to nail down the root cause of this behavior is going to require some fairly intensive (and regular) data gathering while you and your loved ones are working with the application. As per the tech team’s request when you make the observation mentioned here what actions are taking place? For example:

  1. Is anyone in your household making edits to your library ( via various editors we have in the app) ? If so, how often?
  2. What kind of content is being played by you and your family members? Radio\ Local tracks ?
  3. Do you or anyone else regularly re-organize the playback setup in Roon ( re-grouping zones, enabling disabling them etc.)?
  4. Do you usually turn off your zones ?
  5. What are you patterns in regards to the Remote usage ? Do you switch between different remotes or using the same one all the time ? Describe them.

-Eric

I’ll give it a shot, @eric - please let me know if I can clarify.

The only one who routinely changes anything in the library is me, and that’s generally either some cleanup after adding CD rips or downloads into the library (adding music may average once a week or two, it’s definitely not a daily thing), or it’s just the act of podcasts downloaded by iTunes getting recognized by Roon and then selected new episodes being added by me to a playlist of talking we’ll want to listen to.

It would be unusual for library edits to go on at the same time as playback, just because of the order in which I tend to focus on things.

An awful lot is just local tracks, and those usually play without incident as long as I’ve kept the playback zone group sizes reasonable. One day a week we tend to play a lot of podcasts. Six days a week usually start with 2-3 hours of internet radio.

Of course - constantly. In fact, recent zone-grouping UI changes to Roon made me think that the Roon devs / UI designers must for some reason think that zone groupings are a static thing, given the extent to which some frequent operations became less convenient, requiring more steps.

I basically never disable zones - I actually have trouble imagining what purpose that would serve, so the only time zones get disabled in our household is when they drop out temporarily during reboots after software upgrades.

But zone groupings are a constantly adapting thing - for instance, in the morning while prying my eyes open, I’ll usually play WFMU to the Bedroom; then before moving around the house, I’ll generally add the Bathroom and Kitchen zones. I’ll stagger out of bed, feed the dog in the kitchen, then shave and shower.

Once I’m done in the bathroom, I’ll remove that room from the group - because the sound of the speakers in there reflecting from the tile makes things sound subpar in the two other rooms.

When I finish dressing in the bedroom, I’ll want to remove the bedroom from the zone grouping and just continue listening in the kitchen while I get a bite to eat; but here’s where recent damage to the Roon UI makes things more difficult:

  • If I initially created the Bedroom/Bath/Kitchen group starting with the bedroom, for some inexplicable reason I can’t now drop the bedroom from the group: the first zone in a group has a special status now which as far as I can tell has zero actual utility for the user. So to drop the Bedroom from the Bedroom + Kitchen group, I either have to do an explicit extra ungroup operation first, or I have to drop the Kitchen (the only zone I don’t want to drop), save the new group without the Kitchen, then go to now playing and transfer play to the Kitchen.

Anyhow. Side rant over. However accomplished, I’ve now trimmed the group down to where I now need the music playing and continue on with the day. But yes, fluid adaption of which zones are playing is an essential part of daily life, and happens routinely throughout the day. I drop unneeded zones because their speakers affect the sound where I’m listening and I’d rather not have that extra source coming out of a too-near room, or because the zone I’m currently paying attention to is lower (higher number) in the Clock Master Priority pecking order than the zone I’m not listening to and it seems silly for the situationally more important zone to be getting the bit-imperfect stream.

Turn off meaning… what? Power them down? If that’s the question, then - no, never. I don’t see what utility that would have. I always want them on the network available to be chosen via the Roon UI.

I’d say 95% of the time I control everydamnthing from my Android phone.

Exceptions would be: while building up a podcast playlist, which I’d do with the Mac Roon application on the same machine whose iTunes instance had just downloaded podcasts; and when building a big playlist for a party or something which I’d also do from a Mac Roon instance - because the full Roon UI, screen real estate, and a real keyboard make everything less frustrating.

Hi Jeffery_Moore ---- Thank you for the follow up and taking the time to answer my questions.

Continuing forward, after having discussed your latest feedback with our techs, the team has asked if you would kindly provide samples of the podcasts you are currently using. If there are some that are routinely being played more than others, those are the Podcasts we’d like have. Our goal is to try setup some testing in house and make use of the same materials you are working with :microscope:

Additionally, the team would like to examine another set of your Roon logs after a full weeks use of the application. Now that we have a better sense of how you are using the application during your listening sessions/daily use, we would like to see what information is presented in the logs traces after an extended period of time. If there is a potential memory leak here, we should see something in the logs after the system has been “banged on” for at least 7 days.

After the above has been completed (i.e “…a full weeks use of the application”) please use the instructions found here and send us over a set of your “Roon” and “RAATServer” logs.

-Eric