Intermittent Track Unavailable Warning with Files Stored on RoonServer Machine

Support
1

I agree with filing a support request. I also agree that if you can run a cable, even temporarily through the house, to the Bluesound that you should do that to see if it fixes the problem.

I would also suggest that you check resource usage on your Macbook (Roon server) when you are having these issues - I get that message on a very fast 8-core machine that has all local files stored right on the machine…it doesn’t always mean what that message implies - i.e. what happens is that the Roon server runs certain processes on a single core and destabilizes itself and causes temporary network issues that result in messages that imply the media is not available when it really means that Roon has maxed itself out to instability.

2

Hi @James_I,

We’ve examined diagnostics from the affected RoonServer machine but don’t see the usual pattern of high endmutation times that characterizes the failure mechanism you’re describing. Instead, we see some novel errors related to network discovery and grouped Zone playback that we’d like to investigate more closely.

You mentioned that local files are unavailable and hypothesized that background processes tend to exacerbate or cause the issue. Are you referring to metadata updates specifically, or another process? We have an open investigation into the single-core maxout users have described in other threads, but as mentioned above, your logs don’t show the same markers (at least in the current set). The more information you can describe about the symptom you’ve encountered, the more equipped we’ll be to assist you.

There’s a strong effort to root out nagging issues reported by loyal users. We’ll watch for your response. Thanks!

3

Hi Connor-

Thank you for reaching out and I appreciate the effort to eliminate these nagging issues. I have been using Roon since 2017 and have built my audio life around it at this point, notwithstanding the frustrations with stability.

Except as described below, I have not had a major issue with local files and I haven’t added any local files to know if the I/O error/corrupt file scanning issues others are experiencing would affect my server. What I have seen was on the Ubuntu server core that when I use the “top” command to check resource usage, when Roon is acting flaky, the CPU usage is between 90% to well above 100% (how that works I don’t know).

When these problems are not occurring, but I am still using Roon to the full on my network, the CPU usage goes from maybe 6% to 33% and usually in the teens.

During the time that I see the CPU usage being over 100%, the typical symptom is that the remotes drop out and flash the message “looking for core” (or whatever that paraphrases). What I think is happening is that the CPU usage gets to the point where the Roon server software just loses the network connection, even though the actual server machine is still on the network.

During that high CPU usage, I also see occasional “file loading slowly” error messages that skip the track - this is both on local files and Qobuz/Tidal. Since the local files are stored on a HDD in the server, it cannot really be loading slowly except that the server software is so overloaded at CPU over 100% that it cannot pull the data.

What you are seeing from recent logs may be different things. I have not had high CPU usage, to my recollection, in a few weeks - or at least it has not created any issues the past couple of weeks. What your team may have seen - I was playing around with a number of streamers - my Auralic Aries was very unstable until was able to reset back to factory and then reconfigure, and it was acting very flaky until then. Lots of rebooting it. You may have been seeing that since it was being seen by Roon for a moment and then dying. That was the Auralic, not Roon.

In addition to the periodic CPU at or above 100%, the other thing that I see frequently is that a track will stop at one second before the last second in the track, and I will have to click “next track” to restart playback. That does not seem to correlate with high CPU usage albeit that doesn’t mean it never showed that symptom.

Often on high CPU usage I don’t see that Roon is running any specific scan process. Sometimes it it seems to be running metadata updates, but not always. I can correlate the CPU usage at over 100% to the disconnection symptoms, but I can’t correlate a specific Roon process to the CPU usage. It does not always indicate it is scanning or updating.

Things seem to have improved slightly since I throttled scanning, but that may just have been a band-aid to bring usage just enough below the threshold of failure.

Finally, I know that Roon has never liked the Realtek audio drivers I use as endpoints. Those are a lot of my endpoints - not for listening, but because that parallel audio feed can run visualizers and bouncing RGB as the system default audio. I have always wondered whether that may contribute to the instability I have seen.

Happy to answer other questions. Let me know what you need.

4

Hi Connor - if your team can check the logs - 6:30-6:40 PM CT USA, RoonAppliance process is running at 84% to 116% CPU usage as according to top command in Ubuntu server.

There was a dropout albeit the queue just disappeared and the zone was lost for a second, that is why I checked.

6

Hey @James_I,

Thanks for the update and additional information!

I wanted to quickly note that during a fresh diagnostic review from your Roon Server, we saw traces that resembled a known Qobuz issue :

Our team is actively working on a fix, so we don’t have any additional information to share yet, but in case you noticed any issues relating to your Qobuz library, this is the likely cause.

We unfortunately were not able to capture the specific timestamp you mentioned in your prior response. We did see a few playback failures when you had multiple active zones playing audio - similar to what @connor mentioned above.

If you temporarily disable your local library, do you experience the same issues?

7

Hi @Benjamin,

I did notice something weird yesterday when adding an album - as soon as I added it, two tags appeared attached to it. They were oddly appropriate, so I assume I actually already had that album in my favorites and the issue you mention is why.

In terms of the CPU load with certain Roon processes, I would suggest that is a very high priority since it can dramatically affect performance. I don’t understand how you capture logging - can you help me understand so that I can try to note this issue when you can capture it?

8

Right now - 9:45 AM CT on January 24, Roon Appliance is above 100% CPU usage and the spinner in the top right of the remotes says it is adding new music. I haven’t added any new music.

9

Hey @James_I,

Apologies for the delay! It looks like there are two different Linux Roon Servers that have been active with your account recently - ‘ripley’ and ‘sarahconnor’

Which server are you having this issue on specifically?

10

@benjamin

Hi Benjamin - it is sarahconnor. I don’t use ripley as a server right now - I needed an “emergency” endpoint when my Auralic Aries started flaking out so I moved a HDD with ripley on it to a machine to use as that endpoint.

I haven’t looked to see if ripley also has the CPU running wild as happens with sarahconnor. But to the extent that these issues relate to the nature of the library - i.e. the metadata updates that some think are the cause or at least correlate with the issue - this would not happen with ripley right now because when ripley was a server it accessed all my local files as stored on a USB drive that is not currently attached to it, so those albums aren’t present.

My take: if this is related to the nature of the library, it is because I have many albums that will never be identified. I have many DVD-Audio rips, SACD rips, vinyl rips, and others that won’t ever correspond to something Roon can identify. What I would suggest is a way to earmark those albums for Roon to simply stop trying to ever update their metadata.

Thanks

1 Like
11

Hi @James_I,

I think you may be right about this. In your logs I was seeing this
01/31 23:34:36 Debug: [Broker:Media] [identification] <343855> status: CouldNotIdentify followed by Library work going on.

I don’t think we currently have this feature. But we are always happy to get suggestions of new features. You can make a post in Feature Suggestions. The product team does keep an eye on that topic. As a temporary measure you could set background analysis to off which should help with the high RAM usage. Another option would be using the “Ignored Patterns” option in the Edit Storage menu.

image
image695×510 27.2 KB

12

. A user should not have to worry about this at all and not change their library to make it work. There are lots of albums out there with no metadata, Roon needs away to deal with this it should not be a user feature request for basic functionality. Exclusion of files from your library as a result is a bad user experience.

4 Likes
13

Hi @daniel,
Could you explain how would this help? As I understand it, it’s repeated attempts at album identification that’s the problem not audio analysis. Once AA is performed on a track that’s it … it’s not repeated (unless Roon updates AA the algorithm (which IIRC has only happened once).

1 Like
14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.