Keeping multiple cores synchronized?

I have just started to setup a second ROCK core, and the plan is to have that on an additional site/lan. I will keep the music file storage synchronized by using rsync-scripts, but what would the best approach be to keep the music library database synchronized? Should I take regular backups from the “master” core and import/restore on the other, or are there better ways of doing this?

2 Likes

I’d say yes but while backing up a ‘master’ core regularly I would only synchronise the off site cores after additions or significant changes.

1 Like

Yeah , you’re right. The ideal solution would of course be to have some kind of cloud synchronization so that changes you do anywhere would be reflected on all cores.


Another minor issue @support . Is it possible to rename a rock core in any way to something more unique?

We’re working on this, but there’s no timeline for now.

It’s possible to use backup and restore and do ok, but officially we don’t support multiple locations – it’s an important use case and we want to do it right. For the moment, this is a good idea:

You’ll also want to keep your storage configurations as similar as possible, otherwise you’ll need to do this every time you restore.

Moving on:

You can rename any Core from the Setup tab of settings.

4 Likes

You can rename any Core from the Setup tab of settings.

@mike Thank you, but that applies only to what is seen within Roon. I will still have two servers on my network called “rock” and I have to connect to at least one of them using its IP like “smb://192.168.1.XXX”. Wouldn’t it be nice if you could configure your own server/host name on the rock configuration web page?

It would be nice if the database backup was separate from the audio configuration. The collection at both sites is the same, but not the audio endpoints.

2 Likes

There is probably a bigger issue with the “hard-coded” server name Rock that I probably need help with from @support. Since my music storage is locally on internal ssd-drives in both my Rocks, they point to:

\\rock\data > Storage > InternalStorage >

This means that my new Rock points at the music storage on my old Rock. I think that when I bring the new Rock to it’s own site it will find it’s local storage, or? I’m not sure how to move forward but one option (I don’t really like) would be to change the server to \\192.168.1.XXX\data, but that would require a fixed IP. Is there any other way to solve this, for example using \\localhost\data or similar???

All suggestions appreciated!

I have listened my Roon setup for 2 minutes over the last 4 weeks, as evidenced by this fancy new dashboard widget.

Why is this? Because I am figuratively living at my office. Would love to setup a second Roon license and H/W, but what happened to synchronizing Roon meta data (and… OMG! … your music library, as well!)?

Frankly, it would be easy for me to keep the music in-sync. But the meta data sync would be a real pain.

I’ve stopped caring about ‘mobile Roon’, but a second, fixed location would be great.

2 Likes

Yes, agreed. But us local library guys are being put in the back of the bus nowadays, you have seen? :slight_smile:

There is a distinct lack of portability with Roon, from whatever perspective you look at it.

Scenario:
A user with one license has has multiple Cores, at more than one location. The same library is backed up to be accessible to all Cores, to some extent. This dude has friends with lesser local libraries but streaming accounts and of course, a Roon setup.

  • Dude A cannot share playlists with excellent music to his music loving friends as Roon is unable to identify a particular track based on the basic info (track name, artist, recording, year etc) and re-locate it from the other dudes choice of streaming service.

  • Dude A cannot see, what the heck he was playing on system X yesterday as he is at system Y today, hence no History, stats etc.

  • Dude A buys a basket case full of digital albums. As ususal these needs curating and some meta data massaging. They are added to Roon in system X, but it turns out these need manual editing in Roon to be properly identified and find’able. Unfortunately this manual editing needs to be performed at each Core as there is no way to distribute the library between Cores, and is against direct recommendations from Roon (Do not restore a database to more than one Core!)

Well, of course… my response to a 4 year-old thread was somewhat sarcastic. I know we will never get Roon Core portability or any of the use cases you describe above that benefit local library users.

As far as Roon being able to compete with the streaming services; how will that be possible? Frankly, the TIDAL and Spotify apps are every bit as good as the Roon UX. With Spotify Connect and TIDAL Connect, why wouldn’t I just use those apps? Oh, and I can use those apps and listen to music anywhere.

Most devices now have Spotify Connect - even my car has it. Once Spotify pushes out Redbook quality tracks (‘lossless’), auto-magically upgrading my ‘library’ and my 100+ playlists, my local library becomes obsolete, along with ‘Hi-Res’ music, my Bel Canto e.One stream, and my Apple Music subscription (as soon as I use Soundiiz to move my album/artist favorites completely over to Spotify).

It’s as inevitable as death and taxes…

You must have different Tidal and Spotify apps to myself.

They are definitely different to Roon interface but not as good and certainly not better IMHO.

Unless you just want to refer to the mobile and portability aspects…

Tell me about UI features in Roon that aren’t in the TIDAL or Spotify app (excluding the ‘mobile and portability aspects’ or specific to multi-room support, which I can do with other hardware, like Sonos).

I will give you a commonly requested Roon feature that is supported by Spotify: custom images for playlists. Along with sharing with others (another commonly requested Roon feature) - we use this at my agency for social media marketing.

Just jumping in here to say Krutsch was right…