Locating database remote from local install of Roonserver

Is the much better option and I’m guessing that they are working on it.

They are

I am new to Roon and stunned to see that there is no way to choose the path to the database in the installation or option to move the server or the database to a different drive than the reader C.

And what we call a “db” is a simple emptying file into which all the coverart and xml information is dumped. Again, is it possible, to have a real, small and efficient Database?

Yep, depending on your Core OS you can move and link to it.


An interesting rant. Why do you need the option to chose or move the server or the database to a different drive? What are you wanting to do here? In this day and age of cheap storage and efficient processors what is the need for a more efficient db?

You consider these things basic but I could not care about these things at all and would not want Roon to spend anytime on them but maybe I am missing something. If you explain the use case and the reason for your feature requests t is more likely that they will get on Roon’s radar screen.

Answering your query from my perspective not the OP,

Because it’s 2020 and 99.99%+ of apps with databases allow users/installers to choose where to place the db and have for many years. Placing any database on the primary OS volume is bad form historically but then so is running processes as root which is also done.

I’m not sure I would characterize what Roon uses as a database, rather indexes and flat files. It’s in no way relational. I don’t mean to bash and I’m not a database guy but do work with infrastructure so I work with database admins.

It does have the advantage of avoiding the classic ‘corrupt’ database problem non-modern db can suffer when not shutdown properly, etc. But one gives up many advantages too. For example, when an album is deleted the artwork, artist images, lyrics, etc. is left behind. The only thing removed is the reference that causes it to display in the interface. So over time of adding and removing hundreds or thousands of tracks and albums the db gets bloated with no means to clean it up short of starting all over from scratch. This means losing play history, playlists, etc.

Regardless, it was a design choice and I’d bet a bunch of money it’s not going to change.

I would also bet the vast majority of subscriber/owners don’t know or care to know about databases. They just want to find and play music and for this it works fine provided the system the Core is installed upon has enough capacity for the database.

I would imagine that the database etc are inherited from Sooloos so designed some time before it’s launch in 2006. I can’t see a redesign happening until a mobile/cloud version of the library comes along.
Also, looking at bang per development dollar, as @philr says the vast majority of users couldn’t care less or understand if you gave them the option.

Purely as a layman I would give more credence to keeping the DB and the libraries on separate drives. After that I would need to see instances of problems caused by the DB and OS being on the same volume for me to consider it necessary to separate them.

When you have a library of music with over 500 000 tracks or 10000 albums, and that on a i5 with 8 Gig of RAM and SSD, it take 40~60 sec. to Roon to start, It’s the concern I have. So the ability to move a BIG bunch of small files on another drive/partition or better dedicated partition on the SSD will help for management and speed. And why can we change the location of the db/installation in the GUI and not via command-line/scripts ? I’m glad with you that most people don’t know the underlying working of Roon, but why don’t just put the option in the GUI, in the doc and if you have the knowledge and/or the needs to use it, it will be there.

I have more info on the roon server that a friend try to run. He have a lot of track and album. The roon db take 19,5 GB. So when he start roon, even on a SSD, it take more than 30 sec. to start. So what he can do to speed up roon server ? The SSD he have has 1 TB. So my suggestion is to make specific partition for the roon db, put the db in it so he will be only roon db files, fast to optimize and defrag, if needed.

any suggestion ?

I’m not sure this will actually make a difference. Ssd’s do not have spinning heads so partition size and file clustering shouldn’t be needed. They also probably don’t need defragging anymore.

Depending on the ssd he has, it might be worth looking into getting a faster ssd - maybe an nvme drive?

My friend solve the problem; he buy a NUC dedicated mini-pc which is always on. So now, the loading time is very fast (because on his Windows PC, it’s only a remote now - no db to load).

But the main problem is still there; the roon db isn’t a real db. It’s a dump folder of many thousand of hundred of files. My friend still have 146 000 files for a 19,5 Gb in size for it’s roon db. Too much for a decent DB !!! Is roon team looking for analyst or programmer who can do much better than that ?

Why do you think a db will be faster than files on a disk? Think about it this way… you have 20 GB on a disk. “Something” has to read all that information whether it is Roon or something else, it will still take time!

I’m not a database person, so I have no idea whether what Roon actually uses meets your definition, but FWIW,

1 Like

I agree that data must be read. But reading one file (db file) is a lot more speedy that reading 146 000 files to get the same information.

I have a db with 90 000 that was read, throught network and wan, in less than 8 secondes. So locally, on a SSD, reading 146 000 records or more should achieve same time or less.

And the other factor, is the size !!! 90 000 records take 20 Mb fo size. 200 000 should take 60 Mb of space, it’s surely more speedy to read a 60 mb file in a db than 146 000 files for a 20,5 Gb of space !

Foot, meet mouth.

We use LevelDB in the backend. I’ll just leave that there.

OK. I just don’t know this kind of database. That’s alright for me. But how do you explain that a 19200 albums, 207 000 songs database take 20,5 Gigabytes of space ?!?!?!??!?!?! There’s no common sens to that!

And why can we change folder of the DB, move it where we want, easily in the control GUI ? There is my point : Size and location. And location, I can leave with it if it’s a reasonable size. But 20 Gig. Ouf!

I would have thought it is obvious - the database is handling all the objects (artists, albums, performances, compositions, releases, etc.) and their crosslinks - and it is the latter where the total number rises rapidly. Think of the wheat and chessboard problem.