You said these do not depend on time of day.
Anything cloud related could well depend upon time of day (in part at least) because of the variation of loading of the cloud servers. Thus the issues listed by @Suedkiez in the other thread could well be impacted by time of day when doing searches.
By contrast, performace issues that rely solely on the local Roon server performance will not generally be affected by time of day (there are always exceptions).
Nope. I said the OPPOSITE.
I said the list of possible reasons listed by the person I replied to would not depend on the time of day. But my experience it does depend on time of day, and I blame overload of the cloud infra allocated to Roon processes.
Cloud infra is elastic - ie you can dynamically change the resources - which is possibly the most important feature of cloud. But if either the Roon code is suboptimal to take advantage of this, or if cloud resourcing is limited for cost reasons, this would affect performance in times of heavy usage.
You said:
This is not right for the reasons I’ve talked about.
You then said
Which imples you are seeing issues that do depend upon time of day - and so could be any of the issues listed.
What I said is I find performance does depend on time of day. I am not sure what is unclear here.
I also said that I would blame could server performance. That’s it. Couldn’t be simpler.
You said that performance does depend on time of day - we are agreed on that - but you implied, through your first statement, that this meant that this time of day variation could not be associated with the list of factors presented.
I did not. All I said is the factors listed alone would result in performance that does NOT vary over time.
And that is exactly the statement that I don’t agree with. Those factors absolutely CAN result in performance that varies with time of day - at least in respect of search performance.
And with that I am leaving this thread.
Lots of interersting suggestions but none give a clear idea of why we experience problems. ROON is a complex program dealing with a variety of issues, some of which are beyond its control and are possibly microsoft based,
I’m suspicious of Windows Explorer - it sometimes behaves erratically and hangs for ages for no obvious reason. The other issue I sense Roon has troubles with are the wide variety of ways albums are presented. This becomes obvious if one downloads a lot from different sources - sometimes albums come though nicely formatted, other times they require a lot of editing.
I’m cvurrently going back on downloads from my Sooloos days and am giving albums star ratings. Most of these albums are standard CD mode fare which I ripped years ago from my collection. Some appear swiftly while others take awhile to load. Similar picture with play, some continuing to play with directions to play a different album completely ignored for some time. Other times change of album play is instantaneous.
I sometimes rate an album ahead of play but change my mind and try to get back to the album display to change the rating after listening for a bit. Reloading that album, which previously appreared instantly, now takes awhile. And I’ve learned to be patient about changing tags as the first message often is “You have no tags” but that does vanish and the list will appear later.
Another oddity now occurs with backups. It initially states there is a problem, but it eventually settles down and procedes without drama.
Bottom line with all this is it can test one’s patience.
POSTSCRIPT LATER: A reboot of Roon transformed how it behaved. No more lagging of display, either back or forward.
So what is a reboot achieving? Obviously there is an accumulation of data somewhere which slows it all down, but is deleted by a reboot. Weird, although this is not uncommon with Windows - a reboot can transform how the PC behaves.
As several people running roon on ROCK or Linux derivatives (like Ubuntu) experience similar problems, I would not investigate too much into Windows-exclusive problems.
In most cases there is a very simple reason for that behavior. May be it inconsistent metadata, file parameters (such as wrong duration of tracks) or folder structure. I noticed roon being a bit conservative lately with not identifying albums automatically although it works just fine with ´Edit album > identify album´ and the first suggestion in the list. Maybe in future there is a chance to identify albums preliminary in case roon has doubts. That would save me personally a lot of time as a significant number of my albums require the aforementioned extra step (due to wrong track duration of SACD layers in moste cases).
I now try to fix unidentified songs with SONGKONG
Hope, that speeds up ROON
Roon is good at a lot of things, but managing a large library is not one of them.
I use JRiver Media Center to manage my library. I import music, rip music, tag files, build playlist, and delete duplicates, all with JRiver.
When I’m done, my music and playlist are copied on to the drive I use for Roon.
Amen. Same here. My hope is somehow Roon software will be able to manage a large library in the future!
Sorry - my post was off-topic.
@miguelito and @Wade_Oram - what the heck are you guys arguing about? If the two of you were in the same room, face to face, you’d be having a fun conversation about distributed system optimization, not doing what you’re doing. How about shaking it off and recognizing that you both know quite a bit about this stuff and have more thinking in common than thinking that differs?
This is correct and well said. Two very important points here : elasticity doesn’t help if the service provider has capped costs at a point that doesn’t allow for linear scale and/or architectural bottlenecks can be an issue.
I’ve seen both. Things like contention over log writes, garbage collection, off-box calls to things like authentication services, etc. can all cause non-linear performance degradation. We don’t have anywhere near enough information to even guess what’s going on with Roon, but it does seem like something is going on. Could even be regional issues that cause network congestion at certain peak times.
The hybrid approach is hard. I don’t have any idea what they’ve implemented. We know something is in the cloud, but we don’t know what. Given the hybrid approach, there are some other issues that could be in play:
Are the calls to the cloud done in parallel to local search, or are they serialized? In other words, does the client search locally, find a set of results, and then send them to the cloud so that the cloud can search additional content (e.g., services) and then do the merging and ranking in the cloud? Or are the calls to the cloud simply “search this term” after which merging and ranking happens in the client?
Parallelization can be an issue.
If serialized, it’s conceivable that local search time is proportional to library size and impacted by other factors like unrecognized tracks. So if the calls to the cloud don’t even happen until local search completes, that could be an issue.
The size of the payload going up to the cloud can be an issue. If the outbound payload is larger than a single TCP/IP packet, then Nagle’s algorithm might be in play and there may be room to optimize at the TCP/IP level.
There’s just too much we don’t know.
What I think we do know is that Search and other operations can be frustratingly slow and laggy and that it impacts our enjoyment of the product. This is a key reason that when people ask me whether or not they should use Roon, I always say no. I can’t recommend a product that works like this.
There was a time a while back when some Search-specific engineer at Roon was posting updates about Search performance. I wish they’d bring that back. Progress was slow, but the transparency and user empathy were very good things.
We do know local search has been scrapped in some shape or form - obviously you need to know what is available locally but even local search stops working - @danny said something along the lines of “Roon uptime guarantee without an internet connection is zero seconds”
I don’t know how search is done but it is clear there’s a deep convoluted intertwining with cloud-only APIs here.
True but I can’t imagine this is an issue or done that way. My up speed is less than 30 mbps so there would be no reason why this is very fast at times and slow at other times. My ISP throughput is remarkably constant and I have tested throughput during times when Roon is slow and there’s no issue.
There’s a lot we don’t know as you say, but I would surmise that it is clear it is a cloud infra issue on the Roon side.
PS: My hunch is it is both a cost capping on resources AND a suboptimal architecture of the Roon code.
If you’re not familiar with Nagle’s algorithm, this is good read (just a random one I found quickly):
The issue isn’t your ISP…it’s everything in between you and Roon’s servers. You can control the relevant behaviors with settings on sockets.
I’m not suggesting these things are the issue but they can play a role.
The are good, and obviously educated, guesses.
I have on album with 80 songs - should i split it?
Or is the limit exactly 100
There is no such limit. I have albums (box sets) exceeding 3,000 tracks per album. Roon can handle them, but you have to be aware that having a lot of such bringing a lot of metadata links and references (different artists, composers, compositions and alike) will be demanding in terms of core power eventually slowing down things.
One album with 80 tracks you can absolutely keep as it is.
I don’t have a lot of downloaded songs, roughly 1,000, and stream Qobuz.
Roon hasn’t been consistently slow for me. Maybe three instances where it took a moment for one song to load, but that is over the course of months.
Run my Roon server on a separate 2023 M2 Mac Mini with 8gig of RAM that stays on all of the time. I’ve optimized it a bit, removed apps, installed antivirus, it will restart Roon on reboot, and is hardwired to an unmanaged switch and router with Cat8 cable. Network traffic at my router averages around 3mb with Roon and my household widgets (no tv streaming). Roon CPU utilization on the Mac mini varies between 17-41%. If I had it to do again, would have considered a Mac Mini with a bit more RAM, but it runs fine.
Have some experience with Linux Web Server apps, might consider opening a support case and providing some data. Seems like the issue is real, after over 30 years I’ve found that collaboration still works.
I read threads like this and ask why am I not getting performance issues like these poor users. What am I doing right ?
I have used Roon for around 7 years and never see things like this
Some common denominator, to me, are
NAS in general
Core on NAS
Underspecced hardware, processor and RAM
Massive libraries
Obscure albums
Non IDed Albums
In short complexity,
I run
i7 NUC with a 4Tb SSD , 32GB RAM,
Very little DSP
<200 unindented albums
Ethernet all round
AND
I restart all components daily
Just saying KISS …