Artist versus composer

I am new to Roon but this old subject pauses me a problem.
Under the first level of the library entries I find for instance Beethoven as an Artist AND as a Composer.
My original file tags do not lead to this confusion and of all my Beethoven albums only two show this dichotomy.
Any tip to make composers less ambiguies and segrate them from other artists?
In short can I remove Beethoven from the Artist list?
Thank you. J.D

Jacques, to remove Beethoven as artist,your steps are as follows (take care: these can involve big changes and are not undoable)

  1. Select the offending artist (Beethoven) on the Artist page. You’ll want the screen that shows Beethoven as a Performer not as a Composer.
  2. Scroll down, and click on the Select All Tracks text near the right hand margin.
  3. This will cause Roon to pull up all tracks where Beethoven is listed as a non-Composer. Caution: some contemporary composers may have legitimate non-composer roles, e.g., Berlioz as a conductor. Deselect any tracks such as these.
  4. Select View All Tracks (cmd-A), deselect any exceptions like Berlioz, and press Edit in the top right corner.
  5. Go to Edit Tracks/Remove Credits, and put your thinking cap on.
  6. Carefully select (check) for deletion the credits you want to remove. Most likely, they will be Beethoven as a Primary Artist. Peruse the list and consider any other mass deletions.
  7. Press Save, and all Track mentions will be gone. However, if Beethoven still appears as an artist, that means some unwanted Album credits remain.

To get rid of those repeat steps 1 and 2. Then, start selecting each Album, one at a time, go to Edit Album/Credits/Remove Credits and look for Beethoven as a Primary Album Artist. Repeat as necessary.

Good luck, and be prudent. Make backups, test on small samples, etc etc.

Steps 1-6 take about 10 seconds with practice.

@Jacques_DRISCART Alternatively, you can wait until this kind of issue is resolved at the metadata service end rather than mucking about with your library extensively. I realize that this is not an instant fix, but frankly going down a significant editing route is not something that we would recommend.

Note that editing albums can prevent future updates of metadata (depending what you edit).

Elaborate please. Which items specifically?

1 Like

Yes, it would be useful to know this.

Editing an album freezes its structure, meaning we won’t automatically reorganize the track/album relationship in the future as our algorithm improves. For never-edited albums, their structure is managed automatically, so say we learn to recognize a new disc-set directory structure, peoples’ disc sets which were previously displayed as separate albums might join into one. But, if you had edited those albums, we would consider their structure “frozen” and let them remain separate, since joining them would create a new entity that was divorced from your edits. You could always join them yourself using “merge albums” of course…

Editing a field prevents future updates to that field…obviously. Otherwise our metadata updates would clobber your work.

Using “identify album” pins tracks/albums to a specific release forever, so even if we come up with a better one because of a new data source, or new data from one of our sources, you got what you picked.

This is all more or less “common sense” stuff that we need to do to make edits stable + durable while maximizing the possible safe classes of metadata updates that can be delivered automatically.

1 Like

@brian Can you elaborate on this a bit?

[fyi in all cases below I’m referring to a local library – I don’t use Tidal]

Can I get back to an entirely clean slate with an album (or even my entire local library) by using a combination of “revert all edits” and “re-identify album”?

For instance: “Editing a field prevents future updates to that field”

Will revert edits yield a clean slate here?

“Editing an album freezes its structure”

Would revert edits and/or re-ID album yield a clean slate here?

“Using “identify album” pins tracks/albums to a specific release forever, so even if we come up with a better one because of a new data source, or new data from one of our sources, you got what you picked”

In the above scenario, you’re presumably referring to a “manual” ID-album scenario (what we would normally do if the album were un-ID’d or incorrectly ID’d) – could you get a clean slate again by using “Re-Identify Album”?

If so, would a global ctrl-A on the entire local library & then “Re-ID album” give a clean slate on the whole library?

Would one also have to do a global “revert all edits”?

Or would a re-install be needed for a completely clean slate?


I understand that Roon wouldn’t automatically reorganize. However, is there a way to recognize a recently changed set of metadata? If I edit an album because the data is not correct or not complete at the time of my Roon import I would very much like to be able to identify later updates in order to assess and possibly “revert” to the updated “version”.

Is that something you’re considering?

If data becomes more complete or more correct over time, you still get those updates unless you’ve edited the individual fields that they affect.

As far as restructuring of albums goes–we aren’t considering it. It’s a dreadfully complex thing to attempt to explain in a user interface. The reorganizations can be complicated, and a straightforward structural explanation would be incomprehensible to 99.9% of people, and even for the other 0.1% would not create a clear mental model for the possible effects. It’s impossible for us to predict based on a set of new album/track ID assignments exactly how a given user will perceive the change.

thanks for the clarification Brian. I was afraid the whole album would be „blocked“ for further updates. If it is only the edited field, my worries are much less.

Hate to bug @brian again – but maybe he didn’t see these questions?

If not Brian, who should I direct these questions to?


And also with these clarifications. Are we talking about roon edits, rather than local file edits? Or both?

For a truly clean slate, you need the tracks/albums to have new id’s. You can do this by moving them out of the folder temporarily, waiting for them to disappear, using “clean up library” to clear their state, then moving them back.

If you want a clean slate for whole library, delete your database folder. It’s quicker/easier.

1 Like

Brian, there’s a “database” folder under RoonServer, RoonGoer, and RoonOS. To which are you referring?

He’s talking about deleting the entire database, meaing the Roon or RoonServer folder as described here.

To quote the KB:


  • If you are using ROCK, you can find the Roon database in your Data directory"

Go to the Data Directory (mine at least), and one sees this:

So you see, the directions are ambiguous. Which database folder? The one called ‘RoonServer’ which contains the subfolder ‘database’? Or just the folder called ‘database’ within RoonServer? Or some other one or ones?

And, on a different tack: doesn’t the ‘database’ contain track and album edits made over the months or years, the same database that we back up often? Won’t its deletion perhaps cause as much harm as good?

Well, to be fair, what it also says in the page linked to is:

Roon OS’s /Data share allows access to Roon’s database, in the RoonServer folder. While it is possible to swap or replace your Roon database via the /Data share, do not modify the Roon database stored in the RoonServer folder unless you know what you’re doing, as data loss is possible.

Written by a lawyer.

Is the goal a clean slate? Or is the goal to surgically undo some work? I thought we were talking about a clean slate. Yes, that deletes everything. That is what a clean slate is :slight_smile:

I thought he was talking about just one album. I missed his last question. Sorry.