I would be nice to better understand the lag or what should the responsiveness be as a baseline? Having everything “instant” gives me pause whenever I hear that comment. What’s acceptable or “as designed” will be / can be vastly different based on the individual setup as a whole.
I’ve noticed the lag as well but it seems to vary though - as in some days, the lag “seems” more than other day’s, but I never really paid much attention to it. Being roon is not a simple standalone music player (in the traditional sense), there is a certain amount of overhead one must accept, it would seem. 20, 30sec delay to play a tune, no not at all. Again I don’t know what the lag should be, I’m just posing the question.
I recently switched my core from a win10 wkst (hrdwr was getting older) to new hrdwr (small form factor i7-9700, M.2 etc…) running linux server / core with a large TB HD (internal) for local music (replaced my NAS). I also have a high wkst running HQP which then goes to an OR (fiber direct from switch) in listening room.
So I am upsampling with HQP on 2nd wkst and usually get the right to left “Borg” timeline swing 4 times when I start a song. If I have additional songs qued up (whether the entire album or I’m hopping around) that timeling swing is minimal or pretty much instant thereafter (as long as I have tunes in que). I believe HQP que’s the “que” into its memory.
It would be nice to see a video of the delay(s) from others, whether the delay shows how long it takes to play a song and or if its “browsing” ones library.
Here’s my benchmark of what I deem slow:
My library responses are still extremely sluggish (335K songs) also Tidal makes no difference. Switching between the two seems even worse (e.g. a mixed playlist) on average takes 60 sec to move between songs. Switching between Tidal songs 23-30 sec. Switching between songs in local library 25sec and some exceptions (5 secs). No difference if a song is recently played or liked)
On JRiver for example (same library with same amount of songs, No Tidal of course) waiting times <2 second when switching between songs
Yep. I’ve been getting the same results. I thought for sure it was just on my end but it gives me some comfort knowing others are suffering too. Just kidding!
It’s kinda maddening and it’s made me want to use Roon less so hoping for a fix soon!
Yeah, 30-60sec or more to play a song is definitely over the top. I can see queing up a song from qobuz/tidal having “some” delay once and awhile being its an external service which would be out of roon’s control.
I mostly use local (4-5k albums) so a decent size lib and I have been trying out qobuz, but again I’m seeing the 2-4sec que time as stated.
Picking “Home” in roon does take a bit to get there, but guessing it is a crunching stats, local and any streaming content info, dunno? Otherwise if I select album view its within 2-4sec to display. I’ll have to make note of the times later today.
Does the same behavior occur for all endpoints? What if you play to System Output? Do you still see the same slowness?
You mentioned that sometimes it seems to be more noticeable — Have you noticed any patterns? Are there any certain actions that seem to trigger this more often?
If you reboot your Core when it is doing this, do things speed up for you, even if just temporarily?
I was really just relaying my experience to others about the differences in lag times trying to help understand what is the acceptable “lag time”. I don’t have the long lag issues others are reporting of 30-60sec like @Spence_Marquart and @Jilco_Schuurmans are seeing.
I stated I see lags in the 4sec area on average > meaning the left to right in the timeline 4 times. That doesn’t seem anything crazy long. I have experienced longer times than that, but its not the norm at all. I’ll do some testing later today, but I think this question is more applicable to the other two indiv. Sorry if my response was confusing
I’ll try to quckly chime in with my observation - i have noticed on my ubutu-20.04 (i7 nuc) that when this intermittent slowdown appears, roonserver is utilizing 100% of single CPU core.
This is different to for example library scan or roonserver startup, where it consumes all 4 cpus - maybe it helps isolating the issue…
Sometimes working workaround for me is that I select specific (like 1st) track from album - then it starts immediately. Fix is to restart roonserver service.
Unfortunately I have not tried different clients at the same time to see if one would be working, however I have experienced this on Mac, Windows10 clients and iOS in different occasions.
I am playing from NAS to ethernet endpoints (ropieee and custom RPI with roonbridge).
My library is very large - over 275K tracks. I only use Roon for my files - no streaming services. I wonder if this issue is for folks with large libraries like mine? I would think this would be an issue for everyone otherwise.
@dylan i think this has been well documented but please let us know if this is an issue for all Roon users.
Mainly, I hope it’s resolved soon.
Not for everyone. ~22K local tracks on core SSD, Ubuntu Server 20.04.2, i7 CPU, 16GB RAM. Fast album and track retrieval.
It seems to me that the problems described here are dependent upon the library size. One year ago I started my Roon experience with a library of about 56k local tracks. No problems ever. I am now at 185k tracks and I do experience the slowdown after some days of usage without restarting Roon Server. It may be related to what has been described as ‘memory leak’… at restarting Roon Server, on my machine RAM usage is about 3 GB. After 2-3 days of using the system, RAM usage has increased to about 6-6.5 GB. At this point I notice that all interaction with the user interface is clearly slowed down. My Roon Server runs on Ubuntu 20.04 Server, on a machine with Core i5 8600K processor, 16 GB RAM and fast SSD for OS and Roon. I do not upsample, don’t use DSP and stream to one endpoint.
Yes, that makes sense. I’ve slowly built up my library for years. And after upgrading all my equipment including a sonic transporter i9 now Roon takes forever to play a track. I just wish they could give us an update to let us know they’re addressing it.
Right. So smaller libraries no issues.
Virtual or physical? My current usage
1290 root 20 0 5572540 1.2g 252520 S 30.6 8.0 15:27.11 RoonAppliance
IOW, 5.5GB virtual, 1.2GB physical (16GB system RAM).
I’ve been following these descriptions, and rather than a memory leak it really smells like memory fragmentation. Mono is supposed to do compacting garbage collection, but in my experience, compacting GC in Linux can be less effective than expected because of other (eg. I/O buffer) allocations that “anchor” memory segments and prevent full defragmentation. I can easily imagine a bad interaction between Mono and Linux I/O fast object and I/O buffer turn-around create a very fragmented malloc arena. I can imagine this because I’ve seen it in other software that uses object GC on top of Linux memory allocation.
Fernando, I observe 6-6.5 GB of physical memory usage after a couple of days. And clearly the initial physical memory usage after Roon Server restart is dependent upon the library size, which makes sense. I am not at home right now and can not post screenshots to illustrate this point.
I agree with your thoughts about memory fragmentation and the role of GC. And, if this is so, maybe there is little what at that point can be done about that, other than migrate big libraries to Roon OS which seems yo have more efficacious GC.
Having realized this, I have decided to live with this and simply restart Roon Server when I feel it begins to slow down. At least this works well and reliably brings back a perfect user experience. This can be easily be automated on Linux and is no big deal.