I didn’t install B1552 and went straight from 1550 → 1553. I haven’t seen any new functional issue in 1553 and memory consumption looks similar to 1550.
Here’s 7 days of EA. The vertical drop on the far right is the upgrade from 1550 → 1553. As you can see, 1553 so far looks pretty much identical to the last couple EA builds that have included the memory leak fixes. Of course on the far left you can see the tail of the last build that did not have these fixes.
B1553 looks good to me.
I share similar thoughts.
For me, the previous builds were untenable on a nuc8i7 so I went to the extent of procuring a nuc13i5 . On this, Build 1550 was running pretty well. Build 1553, installed and ran okay, but today morning, starting misbehaving “audio file is loading too slowly.” A reboot fixed that. It’s a rock so there is no way to constantly monitor, but I could post the logs.
Maybe I can switch to the nuc 8 and see what’s on with that..
I wouldn’t say this is hardware related as such.
Where are your files stored or do you stream only or is it a bit of both.
Maybe expand on your network setup.
It’s an aforementioned NUC(s) with 16 gb RAM and an Nvme ssd running ROCK. 2GB sata ssd and an attached usb drive fort matted to ext4 for music.
Gigabit backbone mesh network with ASU’s wrt mesh. Wi-Fi nodes in each room. Clients are a mix of airplay and Roon ready. All Wi-Fi clients are tied to the room Wi-Fi node.
Less than 10% of my listening is streaming, it’s mostly from the music which is on the attached drives. Library has about 4.5k albums and 50k tracks
For me there was a MARKED difference in response when moving to the new NUC. Page loads etc are much faster. And music starts much faster after pressing play. (Airplay especially had a huge lag on the nuc 8i7.
Are you mesh nodes wired for backhaul?
Are you Airplay devices on WiFi?
Files loading slowly can be related to an issue with a mesh WiFi system.
On its own, more RAM does not make a computer faster, it’s the CPU. a more capable CPU will aid in pages opening quicker, better UI experience.
Yes, I did say gigabit backbone.
yes and again, the airplay devices are tied to the mesh node in of their respective room, so its no different from a standard lan in that respect.
also std airplay works fine. airplay issue on roon are not consistent and are always correlated to sluggish behaviour of the Roon server (rock).
I don’t know how ROCK uses RAM, so cannot comment, though my library is small enough compared to others for it not be a factor. in any case, my older nuc had 32gb, the new one has 16, (I did not have more 3200ddr ram lying around)
in anywise, the issue I had of slow loading with Build 1553 was with a Roon remote (ropieee) wired to the same Switch as the ROCK.
So, this stayed up on the Titan a little longer than normal, about 33 hours, but then crashed when idle as before…also, I cannot see its memory consumption, because it’s a Titan, but hopefully you’re getting info there.
That’s awful. I suspect someone at Roon is going to have to look at your logs to see what’s going on.
Alas, I’ve been working through this for…a year? Two? It’s getting a little frustrating.
I have been catching up on your support thread for the Titan you have.
@gTunes and I (and others) are seeing a great improvement in this latest EA release.
If you’re experiencing crashes still, but with a great time between them, it’s looking better for you I a weird way.
My thoughts are you have a faulty RAM module or instead of the stock 8gb (I think) you have a 4gb module. I suspect faulty though, which does happen.
@ben are you able to review David’s logs to see the memory levels being reached before crashes occur? My library of 120k tracks is steady at around 4300 to 5000mb
@David_Nanian I may have missed this in your thread, how many tracks are in your library?
I think it’s pretty unlikely that it’s a bad RAM module. It’s possible, of course, but unlikely…I’d expect a crash much earlier, and before it used to crash during the initial indexing.
I have 268K tracks, 20K albums.
Note that I have observed memory usage on a Mac mini (A4, base model), and it’s obviously compiled with a hard memory limit of about 8GB. Even with that, the server consumes Mach ports at a pretty furious rate. A typical Mac process uses very few Mach ports (even the window server uses about 2K total). roonappliance uses hundreds of thousands and they grow and grow until it eventually crashes.
(That’s with pre-1550, though; I’ve been trying to focus on the Titan.)
From the specification recommendations:
Larger Libraries, Multiroom, and DSP.
For large libraries over 100k tracks …
(…)
You will need sufficient RAM for Roon as well as any other tasks the machine may perform. We recommend 8GB as a minimum for Roon
Largest Libraries
If you have over 250K+ tracks in your library, consider us impressed! You’re among the top .01% of Roon users, and you have a library most of us could only dream of.
With libraries this large, we expect the right hardware will work, but it’s not something we test in-house.
Your best bet will be to get a beefy Roon OS setup with a fast new CPU and plenty of RAM, but a very high-spec system running Linux, Windows, or macOS can work just as well.
Well aware, of course. But I’m also quite aware that Roon’s Mono executable has been compiled with a RAM limit, and their top-end server, the Nucleus Titan, should be able to manage a sizable collection.
Certainly, a $500 Mac mini can. Their own top-end server (as opposed to bog-standard entry-level Mac mini) should be able to as well, don’t you think? 
It’s possible that the resource leak you see is the same one that I believe has been fixed in the more recent EA builds. I hoped it would be released today because I’d like to get back to running production but it looks like it won’t be. I doubt they’ll release it on a Friday.
How do you know they’ve compiled with a memory limit of 8GB? Certainly I’ve seen the Linux version consume far more than that as memory use grows due to the recent leak.
I may have missed it but have you said how much RAM you have in your Titan?
@David_Nanian I mean this in the nicest of ways, but your logs said the Titan ran out of memory.
MacOS is a different beast to RoonOS. It’s possible the memory management of MacOS can handle memory allocation and swapping more efficiently.
I would look to swap out the 8gb or RAM for 16, or even 32gb based on your library size and for expansion of your library.
I can see what the macOS version grows to…it may be that it’s 12GB, I don’t quite remember, but you could see it was a hard limit.
I know that the original report, which was a basic search of a basic playlist, that would crash. But as I indicated in that thread, the 8GB was the same memory limit as the Titan. They requested, in a later case, that I provide them with the library, playlist, etc, which I did…
On top of that, here Roon is quite literally idle. The number of tracks isn’t changing. The number of clients isn’t changing. Nothing is…it’s just crashing.
In fact the last crash (last night), I hadn’t even played any tracks since the install of the new update.
So while in the other case they ran out of memory, in this case if it did, it’s due to factors other than the playlist search.
Are you indicating that the Nucleus Titan has a … DIMM that can be replaced to increase memory, even though we can see that the macOS version is limited to 8GB? (I don’t know whether they’re running Mono on the Titan’s Linux setup but I’m guessing they are).
Yeah I found the instructions. I’ve ordered 2x16GB (the suggested DIMMs are EOL, so a downclockable replacement from Crucial), and we’ll see what happens. (I don’t think it’s going to fix the problem…)
Sad that they used an i3. You’d think they’d use an i5 or i7, but…
