System architecture comments: a tale of 3 systems

system 1: a non-roon music system I used for a couple of years. It played back beautifully, but as my music collection grew the user interface became intolerably slow (though playback once started still worked very well)
system 2: my first roon install as outlined previously, using a dell laptop for core. unusable. danny has pointed out that this is due to a lack of SSD given the size of my music.
system 3: A Rock system using a roon-recommended NUC model. does everything well.

Danny, do you really want to be of any help for ROON-clients? @enno @Carl

Oh, great, the first sign of life from @danny , after very long time yet again in another thread and not where the questions have been placed.
I am not happy at all with the arrogant, defensive style of your reply, Danny, deeming the ROON-clients to be somehow idiots and have self-inflicted their problems. I understand that networks are a tricky issue. But the MINIMUM I expect from ROON is a good system of error messages giving hints on where an how the problem arised. I do not want to retrieve in a complicated way protocols while having poor response on them. In this case of skipping 1.7 provided at least one error message, with 1.8 there is no message at all while the system is stuck in an endless loop.

I would like to see the responsible head of department or the CEO involved in the dissatisfactory way, how ROON-customer-service is dealing with customer-problems.
Communicating this way between ROON and clients who are left down by technical problems is not acceptable anymore, danny!
Danny, please help, but do not ridicule ROON’s clients!
Do you want me to warn potential new clients about ROON or do you want a satisfied community?

Whenever I see reports of skipping tracks, in 80% of them I believe I can walk into that home and point out where the problem is or even fix it. That is after a significant time trying different things after having those issues myself. That is the reality. And it has to be said that as distressing as it is for the users with the problem, 35 examples of skipping tracks in a product with an estimated user base of over 100k users is actually pretty good. Being able to see every support thread raised can create a false illusion of fragility.


@Danny. Thank you for looking into this. It was not my intent to do “a disingenuous thing” and I am sorry if I did. But is it “a disingenuous thing” to try to make clear that there are tens of users experiencing playback issues? I honestly don’t think so.

Are most of the skips linked to either networking or under-spec’d hardware? I am sure some of them can be explained that way. But users with fast internet and hardwired connections to their core and endpoint plus decently spec’d hardware are experiencing the problem too.

Has none of this to do with Jim Hamilton’s question? Well, I can be mistaken, but it seems to me that skipping of tracks during playback is a perfect example of the problem that Jim states in his original post: “interrupted playback should not occur”.

I believe everyone would benefit if the recurring playback/skipping issue was treated as a problem that seems at least partially connected to Roon and that should therefore be addressed by the Roon team.

Just to try to draw your attention to the fact that users with a (seemingly) fine hardware configuration and network, experience the problem too, here are some examples:

Roon skipping tracks since last week This one experiences skipping with Tidal tracks and uses an Intel Core i5 with SSD and ethernet connections. He mentions that he does not use multiple zones.

Roon Radio stops or skips tracks This one reports skipping with Roon Radio and Tidal. He uses an Innuos Zen Mini Mk.3 and experiences it (among others) on a Naim Su-so 2nd gen endpoint connected via ethernet. Another user confirms having the same problem in the same thread.

Tracks Not Completing and Skipping To Next Track Here you will find 9 users experiencing the playback/skipping issue. The original poster uses an iMac Intel Core i5… but wifi. However, at least one of the users who report the same problem uses a 1Gb business grade internet and wired connections (Tracks Not Completing and Skipping To Next Track - #3 by Robert_Goodhope)

Occasionally Song abruptly stops and skips to next song A subscriber with a Sonictransporter as Rune core and ethernet connection to a Lumin T2 network player experiences songs abruptly stopping and going to the next song.

Playback skips to next track A subscriber experiencing glitches with playback (MacMini i7 core, ethernet connection to PS Audio DS Jr).

Titles Skipping constantly A subscriber with a Roon Nucleus and ethernet connection to Lumin U1 Mini & Bluesound Node 2i experiences skipping with Qobuz and Tidal tracks.

Etc… etc…

Maybe the basic thing to consider is:
Does Roon want to keep on repeating the mantra that if a user or tens of users experience glitches and skipping in playback… the problem is at the (nagging) user side of things?
Or does Roon want to solve the apparent problem using the subscribers and community posters who report the problem as allies who are more than willing to provide all the possible details in trying to help?


I’m not a habitual contributor to user forums, and would like to get off this thread, but I feel a need to address danny’s latest response to me. I appreciate the comments from others including francois…
this is a bit confusing since related content is contained in both this thread and the “playback skipped” thread, and danny’s latest response to me is there.
danny, peace. You stated that Roons software is “way better than you seem to think it is”. well, I’m not making any critical global comments, I’m trying to address a fairly specific shortcoming. As for my opinion of Roon, lets set it straight:

  • I have taken the time to install roon on two systems, and to incorporate my large music repository on both. despite problems with the windows system, I spent $800 on a NUC dedicated to Roon, and am about to end my trial with a year’s subscription. In these threads, I have repeatedly complimented roon for its database approach, which is the correct way to do this, as explained in the knowledge base, and based on my experience. I have taken the time to read pretty much the entire knowledge base. (I confess to not yet having learned enough from the forum). Roon is ambitious and doing a great job.
  • My NUC/roon system is fantastic. its is responsive, I have not experienced any errors, and the sound quality from the NUC USB output to my fairly high end system (benchmark dac/mark levinson monoblock amps/martin logan full range CLX electrostats) is the best I have obtained.

so lets not be prickly. I’m just trying to help, and I have a lot of experience with complex software and networks. (distinguished engineer, VP of software, chief network designer, Software research manager, etc). Of course, I know little about your code.

In my last message on “playback skipped”, I tried to present a couple of cases. case one was:
“the system slows or stops scanning and background audio analysis. metadata retrieval is sluggish. A scan of my repository takes 5 times as long as it should. My tracks still play, though search and selection are slower than usual.”
your response was:
“It does exactly this. It runs at a very low priority and uses a single core by default. Unlike playback, which is run at a higher priority and usually single core”

no. in my scenario the playback continued. In real life, with an overloaded core with no SSD, playback repeatedly stopped. Sometime it resumed by itself, most often I would hit play and it would continue from where it left off, and sometimes I would get a message that communications with the core were lost, (and restored after a pause, though the playback had to be restarted from the beginning). This problem was exactly my point. Please explain why the absence of an SSD should cause a playback stream of a few hundred kilobits/sec to be interrupted. My poor previous system, using a pi “core” and struggling with my large repository, never did this. To your second comment, as I indicated here the remote did not always die when the audio stopped. I also want to mention that there was no DSD processing involved. All the core had to do was to get those bits to the bridge/DAC. this is not a lot to ask, and other systems do this.

You seem to feel that all the users who report skipping or playback problems are under resourced or misconfigured. You even called someone trying to address this issue “disingenuous”, which seems really unfair.

I have simply asked for a look at how to isolate playback from background processing so overload does not impact listening as frequently. The evidence clearly shows this is not currently the case. I thought I was initiating a small thread to point this out and suggest improvements to a system I really like, not start an adversarial conversation.


FWIW, i host Roon on an i7 Mac Mini 2012 with a 1 terabyte SSD. All my content is on a Synology server. I also experienced playback skipping until I increased RAM from 4 to 16GB.

1 Like

interesting point, but similar symptoms can have multiple causes. I have little experience with WAN streaming, but can certainly see how a VPN might help by changing and stabilizing the data path.
I think the process and resource management in the core software is a more basic issue (and more under roon’s control). I’m new to this forum and to roon, but suspect that a lot of the frustration with 1.8 that I read may be traceable to a lot of new features which have exposed these underlying architecture issues, resulting in a greater likelihood of user visible errors on a wider range of platforms, especially towards the lower end.


In this user’s situation, using a VPN from Brazil would use a totally different set of TIDAL servers. This solution working demonstrates no problem with anything at his location (Roon, hardware, endpoint, network, etc). It’s all about which TIDAL server he streamed from.

1.8’s hardware requirements are actually lower than 1.7’s because we did a bunch of optimization work in the local pieces, and most of the new “heavy” functionality is being driven from our cloud services.

its not the overall hardware requirements I’m addressing (though its great that roon did the optimization work), nor is it why my modest windows box failed (though thats nice to understand).
its ** what the system does when it runs into problems**.
here are 2 hypothetical results of an overload or other problem:

  1. the system slows or stops scanning and background audio analysis. metadata retrieval is sluggish. A scan of my repository takes 5 times as long as it should. My tracks still play, though search and selection are slower than usual.
  2. I’m showing off my spiffy system to friends, and while listening my miles davis “kind of blue” DSD abruptly stops. core disconnects and my user interface is gone.

for some failures, both errors are inevitable, but for many overload conditions, proper prioritization and sandboxing can preserve critical functions ( which I consider to be playback and core access)

which door do you choose? In many cases, with a properly architected solution, an overload or other resource availability issue need not bring the entire system to its knees. I have seen no recognition of this in any of this discussion, yet I feel it would be of value to users and to roon itself to look at this. Its routinely done on mission critical systems (which I worked on for decades), and it was done on my previous music system.

It does exactly this. It runs at a very low priority and uses a single core by default. Unlike playback, which is run at a higher priority and usually single core.

If the remote dies at the same time your audio stopped, it means your Core died (power or crash) or the network failed (and you are streaming with minimal buffer).

Because it’s basic software development practices for a system as complex as Roon. It’s not perfect, but it’s way better than you seem to think it is.

You’ve made a decision that Roon does nothing like this because you hit SSD vs HDD issues for a large db that blew it’s write locks and everything hung up. Roon isn’t an RTOS, but if you use reasonable and reliable hardware, it works well. If it didn’t, the # of people complaining about skips would be tens of thousands, not tens.

I’ve merged those posts into this topic as I feel they are more fitting here than in someone else’s #support topic … Apologies if the timeline looks a little odd now, I’ll see if I can fix it.

1 Like

A post was merged into an existing topic: No appropriate error-messages from Roon

The Support Team is working on those issues and neither you nor I know what the issue is. I’m looking at patterns of identified issues, and they are almost always resources or network.

I’m quite active, I just have nothing useful to say in the HRA thread that hasn’t already been said.

When statements are made based a few forum posts about the Roon population as a whole, I’m correcting that misunderstanding. The Support Team is dealing with support issues, not me. I was addressing a tale of 3 systems where one was under spec’s for Roon. @jim_hamilton wants Roon isolated with cpu time slice and thread guarantees like the way an RTOS has. I’m telling him it designed with this stuff in mind, but without a full RTOS-like guarantees. None of this is ridicule.

No one but you has said “idiots” and yes, most issues related to this type of issue are self inflicted. There are other areas (like metadata) where this is not true, but “skips” are almost always environmental, and usually due to setup or beyond the users system (TIDAL servers).

1 Like

Well, all those examples that “neither you nor I know what the issue is” come from my “desingineous thing” I did according to you. To be called disingenuous for pointing in the direction of an unsolved and recurrent issue… it is not the way I am used to being treated as a client, nor as a human being.

1 Like

You are painting a picture… The reality is there are a similarly small number of complaints at all times, and they generally get resolved.

Your situation will resolved by support, but you’ve decided to get up on a soapbox. As a person, that behavior is antisocial and would get you physically removed from most establishments.

No one is saying you don’t have an issue. No one is minimizing your issue. You are feeling my response to your soapboxing.


Seems to me like a case of shooting the messenger. But I will leave it at this and start some introspection about my disingeneous and antisocial behavior.

1 Like

7 posts were split to a new topic: There are new rules out there for the blog

This thread has run its course. Perhaps the prudent thing is just to let it, but I feel a summary might be useful, since a number of points were raised, and relevant posts were made in 2 different threads. The moderator nobly attempted to merge, but the flow is now confused, and my original summary is now in the middle of the thread. Here’s a coherent (ok, you be the judge)… summary:

I’m pretty new to roon, but I’m pretty experienced with many digital music management/playback systems. My initial look at roon, as already described, was on a simple intel laptop, which as it turns out did not meet clearly stated roon minimum system requirements due to its lack of a SSD. I did not expect this system to perform well. Part of this thread focuses on the shortfalls of this system, and fixing these shortfalls by migrating to a much more capable system. This misses the point. If roon had simply performed poorly on this system, I would not have posted. My point was the way roon failed: by completing database population and allowing connection and control, but then failing during playback.
The fact that the system had glitches is somewhat moot, given that it was under-resourced by roon standards. The fact that it failed during a mission critical operation (playback), which itself should require minimal resources, was the point. As a experience system architect, I know this can be improved using known techniques. I had hoped that highlighting this would be helpful. From the comments a number of forum members understood this. My observation is that roon had not isolated playback from other systems issues, could do so, and this would provide many benefits for both current satisfaction, future growth, and ability to use systems with less resources. Here are the key takeaways as I see them:

  1. @henry stated that 80% of playback problems are user issues that are easily diagnosed and fixable by a knowledgeable person. I completely agree. But that leaves playback problems that may point to areas of improvement for the system.

  2. @Bob_Lindstrom reported that he resolved playback issues by increasing his system RAM. I suspect there are more cases where people had issues and resolved them by using more capable hardware. System architects have long had a name for this: throwing hardware at the problem. you can mask many architecture issues by simply over-resourcing the system. Sometimes its even the right answer. However, as your system features grow, or user collections grow, this may come back to bite you.

  3. somewhere in the now-somewhat confused thread merger it was pointed out that problems with playback have affected only a small percentage of users. I have no way of evaluating this. This does not mean that insulating playback from background system activities is not beneficial.

  4. finally, since obviously I know little about roon architecture and software, how do I know playback is not well sandboxed currently? Well, it only takes a couple of test cases. I feel I inadvertently performed one. My windows system repeatedly (several times in a listening session) would stop playback, usually about 10-20 seconds into a track. sometime it would recover, most often I would hit play and it would resume (from the proper location), and occasionally the problem was likely more serious since my controller lost connection to the core (@danny suggested the core crashed in this case) and I had to restart the track after reconnection. I was playing a mixture of flac 16/44 flac 24/96, and DSD 64 and the problem occurred for all of these. To the @henry point that most problems are user configuration,
    a. I was doing no DSP (verified by roon), and no WAN streaming
    b. my fileserver had been used on multiple systems pre-roon and I had hardly heard a dropout in 2 years. The cat 6 switched 100/1000 ethernet delivering the bits has been solid for years. The ROPIeee bridge could be questioned, but this seems very unlikely.
    c. The roon system was not being used for other applications at the time of playback.

put the above together with what is required for glitch free playback in this case: the core’s only job (e.g. for 16/44 flac) is to deliver, in “near real-time”, a bit stream of a few hundred kbits/sec across a switched ethernet to the bridge. a raspberry pi model 1 could do this. I was doing this in 1980 on corporate networks. Many of the tens of playback systems I have used over the years did this (although they mostly failed in database performance, unrelated to playback, and become unusable)

I apologize for the lengthy message belaboring the point. Roon is a magnificent achievement. On the right hardware (NUCi7model10, the highest performing server listed in the knowledge base recommendations) it has handled my 17,000 album database with ease, provides snappy control, and, using direct USB to my benchmark DAC, gives me the clearest DSD playback I have achieved to date. Sandboxing playback (or at least providing more guaranteed resources if the system is busy) has many benefits. Its not trivial, but the techniques to isolate critical functions are well known. @danny says roon already does this. then why did my playback fail? clearly, in this case an under-resourced core failed to transfer bits. pity.