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)
- Select the offending artist (Beethoven) on the Artist page. Youâll want the screen that shows Beethoven as a Performer not as a Composer.
- Scroll down, and click on the Select All Tracks text near the right hand margin.
- 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.
- Select View All Tracks (cmd-A), deselect any exceptions like Berlioz, and press Edit in the top right corner.
- Go to Edit Tracks/Remove Credits, and put your thinking cap on.
- 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.
- 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?
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.
@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?
TIAâŚ
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.
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:
"On ROCK,
- 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
I thought he was talking about just one album. I missed his last question. Sorry.