There’s a mix of things in there! Some of those don’t need you to do anything extra as roon will notice the changes and some “it depends”.
I would make a numbered list of the things you want to do and then everyone can help classify and reply.
One current task is to normalize (change) folder names. Also, I would combine multi-disc sets into a single organizing folder. That’s one task. I suspect this type of change is most prone to havoc.
Another task is a long-term project of mine to change composition names to their canonical format a la Allmusic. These are often done album per album. Usually, I’ve will leave the album in place in the Roon watch folder, use a third-party tagger, and make changes “live”. Sometimes I may also need to add or update DB tags (mostly from MusicBrainz, sometimes from Discogs). But again, I don’t go through the trouble of “export/delete/change/import” process described in my OP.
A third primary task is a “do-over”. Either the number of edits required is large, or Roon won’t let go of a prior incorrect ID. For these problem cases, I use the process described in the PO, then re-tag, ID, and/or renumber and then re-import. But on two occasions, Roon seems not to notice that my refurbed albums have been added to the watch folder. It is then that I am not sure how to proceed. What I have resorted to twice is to unlink and relink the watch folder. Then Roon will pick up on the refurbished album(s).
A fourth task is to occasionally use my Tagger (Yate) to make bulk changes, i.e., adding a canonical composition name to all the different performances in my library at once.
Not sure I answered your question. But I’ll stop here.
I would still opt for either using 2 differnt terms
delete = wipe something so that it’s gone in the end
remove = turn it not being within roon’s database any more, while keeping in on the storage media
Show a windows which does tell
DELETE from database
with an extra option one must tick named
ALSO DELETE PHYSICAL FILE(s)
Since then it’s more visible about what’s ment when reading DELETE.
From scratch, if one does work with database backed software 90% do work in a way that removal operation tend to work upon the database only.
I mean this in the best way, but sometimes we get a little ‘obsessive’ about folders and files and naming conventions and metadata . . . and it feels comfortable to “fix” it. Unfortunately, our servers are less obsessive and don’t quite interpret our fixes!
Trust me, folks, I’m not being terribly obsessive. My library was a mess. Folder names were just one of several tasks and only involved a minor part of the tasks. That said, I have had a few albums, where I changed folder names, that were in Roon’s watch folder but never would make it into the DB. Not corrupt, not skipped per se, just ignored. So I inferred that my workflow was flawed somehow. Hence my OP.
Most of my time has been spent tagging files in an effort to increase the “hit rate” on composition linking. My experience suggests that Roon’s algorithm used to ID compositions is, er, conservative, bordering on timid. (I am speaking from the perspective of a mostly classical library.) So getting the WORK and PART tags populated with accurate (a la Allmusic) canonical names has been a major effort. If that’s obsessive, color me guilty.
I like the additional information that comes from linked classical compositions. Also, I think Roon has reached a point of diminishing returns on improving its recognition rate and on metadata generally, particularly for classical stuff. And, I have seen the shoddy quality of the DBs it must use. Finally, I’ve been reminded often that my interests are in the distinct minority.
So, I have concluded that unless my naming and tagging is letter-perfect, composition recognition will continue to be a hit-or-miss affair.
Good question. Let’s just say I had been inviting trouble, hassle, and potential disaster if I had to make a quick shift of vendors. I had allowed Roon’s admirable track record for recognizing/organizing non-classical stuff to make me lazy about scrubbing tracks before importing them.