Just a bit of perspective, I WAS running the core on an antique (2010 mac mini core 2 duo with an SSD) when in my trial period and it ran really well with my 35K tracks.
I assume you meant to send this to @Matthias_Dauelsberg, since your mention of “with an SSD” is exactly the perspective I have. SSD makes more a difference than anything else.
Very curious: have you ever experimented (or considered to do so) how this knowledge (networked relationships) would integrate/ perform using a Graph Database?
I don’t know whether they have experimented or planning to do so, but what I know is that DB migration is a heavy process (particularly having so many customers) and -unless there’s a 1/10 performance ratio- it won’t be worth tempting it.
What embedded graph DB performs better than in-memory indicies?
I’ve mainly had experience with Franz Inc.'s AllegroGraph. Got excellent performance over very large graphs (hundreds of millions of nodes and billions of links). Have to write in Allegro Common Lisp, though. And I certainly wouldn’t use it on the client side.
On a circa-2011 Mac Mini with a spinning disk, or real server-side hardware?
Exactly, not at all embedded.
Graph databases remind me of flying cars and Linux on the desktop… promising implementations exist, but in the decades I’ve been hearing about them, they’ve never gained any real traction. Bah humbug. Color me not impressed.
Hey! This is the year of Linux on the desktop!
Man, that was such a running joke on slashdot decades ago and it still makes me smile…
You have to be using graph algorithms to make real use of them. Limited applicability.
I used AllegroGraph on everything from real server hardware running Linux (a Red Hat variant) to high-end Mac Pros. No minis. Always lots and lots of RAM. It did pretty well on top-of-the-line MacBooks of the time, as well. But this was 2010, so…
Got it. Never mind.
Roon 1.8 is out soon, what are the chances of it supporting 1M+ library sizes?
I’d given up getting a platform that supported my music collection, I tried everything affordable on the HW front and support ran me around in circles posting Roon logs back & forth. I’m no expert but a few things seemed obvious to me. Roon isn’t scaleable due to it’s single core design architecture. Hoping V1.8 breaks this constraint.
Can you try to shuffle with your big library in version 1.8?
If I do shuffle within titles, only interprets starting with A is playing. It adds 5000 songs to the queue, which was not in version 1.7
Same, 5000 added to the queue, I never tried that before so can’t confirm whether it performed differently in 1.7.
I don’t remember 1.7 showing the number of tracks added with Shuffle. I always had the next song appear at the right-hand side with the option for me to give it a thumbs up to add it to the queue or a thumbs down. Either selection caused the next, supposedly random track to appear to the next “thumb” selection.
I am curious to know if this 5000 track option when selecting Shuffle is random with no focus selected or if it only pulls in the same 5000 tracks. Don’t see this information available anywhere. I’d really like to know how Shuffle works and what the intention is supposed to be for how it works.
I have a library of 726k tracks that I manage with an iMac running roon server. I‘m relative new to Roon but after 5 month I got it to work. Roon Remote is on my iPad and it‘s stable and responsive.
@Brian, this post is really helpful and somehow I overlooked it and its 2018 update until now. I wonder if you would consider updating it sometime soon with the current state of Roon’s thinking on these issues of serving very large libraries most efficiently.
If memory serves since 1.7 ROCK has had performance enhancements implemented that are not available in the general Roon Core for Linux.
I’m not sure about that.