Only Cover Art Remains

I have, and I know that it is not possible to design a foolproof system, ever.

So we ae talking the same language then. Agreed that an entirely foolproof application is impossible. But due diligence demands that we make as much reasonable effort as possible in pursuit of that excellence. I don’t see massive evidence of that on the library delete function. Data is supposed to be inviolate. You don’t mess around with your source version and you try very hard to ensure people don’t delete it accidentally. Its not enough to say “despite warnings, you went ahead and did something stupid
learn from it”. I bet many who have deleted the odd file from their library do not realise they’ve lost it forever.

I sense that you and I are never going to see eye to eye on this, so lets just agree to disagree!.

I want the ability to delete files using Roon. My library is too large to hunt through individually.

Perhaps if instead of a button you had to physically type “DELETE” or similar it would make people think a little harder about what was going on.

1 Like

@Reg_Basimi, sorry you’ve been tripped up by this and I’m so pleased you have managed an 90% restore.

Personally I think Roon is quite clear with its warning however I still don’t like it.

I believe that Roon should never delete library files, it’s always of concern when I had over my Roon Remote for someone to have a play with as mistake can happen.

If there is to be any library file management then Roon should instead move the files along with their associated folders (and any other content in those folders) to a “RecycleBin” folder structure within the given ‘watched’ folder.

  • Once moved, Roon would ignore them, so they don’t come back i.e. don’t scan the “RecycleBin” folder sub-structure.
  • Once moved, the user can via non-Roon tools manage the “RecycleBin” folders/files as they see fit.

I agree. Roon doesn’t “create” the files and therefore shouldn’t be able to delete them. For me, Roon’s ability to work with my existing library, without changing it, is a major plus. Until reading this thread I didn’t know Roon could actually delete files.

Good suggestions offered. Given music files are a special breed of files, management should treat them as such by removing them without deleting them permanently. Hence iTunes’ saving grace after clicking on delete followed by the query, keep files?.

In my view roon is a marvelous program with highly innovative features and synergies that open our libraries to views and uses for information that, in my opinion, is incomparable.

I am wondering what advantage it is for us to use roon to delete tracks/files permanently versus removed them from the library folder(s). Thus preserving the music for the member to decide whether to delete with prejudice (smile). Still the responsibility for actions taken notwithstanding we are all Humans-In-Training and make mistakes that surprise even ourselves when revisited. I wonder, therefore, what roon’s oracles think about this discussion and whether or not the delete operation needs to be revisited to allow for more flexibility with the fate for our music files. I concur that the warning is explicit and sufficient to forewarn against losing data permanently. And at the same time would appreciate that the innovations so consistent and forward may allow for a different outcome for music tracks/albums deletions for our libraries.

Curious what the general perspectives of the membership would prefer. It would seem possible to acknowledge any of several outcomes unless I have that wrong about the totality of responsibilities for making deletions happen.

Thank you all for a civil, thoughtful discussion, and moderation.

Enjoy the music,
Richard

Hi Richard

Since you are asking for opinions on this topic:

  1. I value the ability from within Roon to somehow remove files I no longer want in my library

  2. I think that the warnings currently provided are clear enough

  3. I agree that moving those files to a “Roon Trash” folder, on the same drive where they were originally located, would be a good failsafe, but personally I do not feel I need it since I keep 2 backups of the music files anyway. However, if it becomes a feature, then great (as long as it does not delay the development of some form of built-in room correction) :slight_smile:

Z

The only solution (or remedy) for human frailty in data management is having one or more really good backups of your data. No software engineer can design a UI that will save us from ourselves.

I consider myself well above average when it comes to computer literacy (and others have reinforced this self-image), but I’ve still done incredibly embarrassing things with mission-critical data in the past. And I expect I will again in the future. The only thing that has saved my butt (repeatedly) is a consistent and reliable backup strategy. And no backup strategy is “reliable” until you’ve actually used the backup to restore data and software. Be disciplined in making regular backups, and give yourself real peace of mind by testing the backup software’s restoration function.

Cheers,
Jeff

3 Likes

Couldn’t have expressed this perspective better. That is precisely my conclusion and in deed backup reliably after every listening session when adding new albums/tracks. Also save the database religiously as well on a separate Raid 5, so I am three deep with the roon database as well as my entire music library.

The ultimate responsibility for our music library (ies) rests with our mindfulness about and routines that perservere so we don’t have to perspire after an unfortunate mistake.

I did not mean in any way to pass that responsibility (ultimately) on to roon’s operations. Merely, if doable, ecological and in roon’s control, a method for helping us notwithstanding the conspicuous caveat that may slip past our awareness until it’s too late. A slap on the forehead accompanied by “What was I thinking?” Is too late. Lessons learn from examples proffered in this thread is very helpful to remind us of what we already know.

So we can enjoy the music,
Richard

I originated this thread because I deleted my Roon library and in the process also deleted my source files. The consensus here is clearly that the warnings given were adequate. The warnings were clear that what I was about to delete would be lost from the disc forever BUT it was not clear that the library and my source files were one and the same thing. Now that its been pointed out to me, I will not make that mistake again. Still, this is such a departure from standard practice, I think Roon should flag it with a great deal more noise.

I am a relative Roon newbie and spent most of yesterday playing around with the Roon storage facility while re-creating my library. I now see the value and added flexibility that comes with the library just pointing at a data source rather than making a copy. Merely by enabling/disabling folders you can change you library with just a few key strokes - brilliant! I can now do separate folders for playlists versus albums, and other assortments.

So, if we are going to manipulate source data, how do we ensure its safe. Well, I agree that the first step would be to introduce a “cooling off” mechanism so that we can review before deleting forever.

One thing that’s come out on this thread is a heavy reliance on backups as the final solution. Backups may be simple in concept, but in my experience, they are not necessarily straightforward in practice, certainly not for the non-techie. For me, a backup is only a reliable provision if a restore has been performed successfully on another machine, which is what would be needed if the original machine were lost in whatever way.

For just music data, I am more comfortable with secure copies. You can re-use them again and again anywhere; although yes, keeping them up-to-date can be tricky. We once had to restore an Oracle Council Tax database and nearly failed because some of the redo logs were corrupt. Luckily I had taken the precaution of making 2 separate copies of those logs on to tape. Is there anyone here who can educate us on the relative merits of backups versus copies for music collections?

Do you mean by this that you are changing the Watched Folder paths just to get different views of your library? If so, it seems like an awful lot of faffing about to me. You could get the same result by using the Focus and Bookmark features. No need to lift the hood and rearrange data paths
 :slight_smile:

[quote=“Reg_Basimi, post:30, topic:13542”]
Is there anyone here who can educate us on the relative merits of backups versus copies for music collections?
[/quote]Hi,
To help with answering that question can you clarify what your definition is of these two terms?

  • ‘Backups’
  • ‘Copies’

I’m seeking clarification as for many they might be considered the same.

You may well be right but I’m new to Roon and taking baby steps! By the way, does Roon allow user-defined criteria for Focus selection? Thanks

See what you mean. By copy I mean a straightforward copy and paste/drag and drop of the specific data files/folders to a specific location. You can take those files to any location, hook the drive to any machine and access the files.

By backup, I mean use of backup software to save and restore. This usually creates images that cannot be accessed/read until restored using the original software.

Why not use user-defined Tags for this purpose? You can define Bookmarks for specific groupings of your user-defined tags as well.

1 Like

I am a big proponent of utilizing the user-defined Tags.

I appreciate how one can distinguish as Reg_Basimi has between removing/deleting files from Roon and deleting the source permanently so as to be unable to recover those files. Hence the reason I continually refer to how iTunes reminds one to “Keep Files” as a method to avoid losing those files forever.

I never argue with perception. And, my experience with backing up could not be easier (or quicker). I have been employing one particular backup program since 2008 with proven restored backups when unfortunately needed. My outcome is not to promote a particular program, rather to point to an easy way to make an exact copy of the data I chose to backup. Essentially it’s a copy of the original source. And the protection it affords me is priceless.

Given the differentiation between copy and backup, I have just violated a member’s perception of the two different “words” and what they refer as a backup versus a copy. In my experience, these two terms are used interchangeably. The backup is a copy. It can be restored and used to replace. Or accessed and used as is given it is a copy without restoring.

Super Duper for the Mac allows me to conveniently backup any data source. Initially, the time required to make the first copy may take much more time compared to incremental backups that merely record changes to the original. The restore function is reliable. I can also open the backup and use it as the original without restoring. Thereafter, the backups which add or subtract changes made to the data source are accomplished in minutes.

This allows me to keep my original music libraries safe and restorable if some unfortunate occurrence makes that necessary. It is easy to create and maintain. All that’s required is a partition on a HDD (other than source) or whatever source for the backup one chooses.

There’s no reason not to create and maintain backups of the original source with confidence (fingers crossed). Or multiple backups. Or multiple backups of multiple sources.

Whether or not Roon decides to implement an intervention to protect the original source files notwithstanding their admonition when one’s finger is inclined to push the delete button, backup, backup, backup source files and Roon’s database.

And enjoy the music,
Richard

If you give your core machine only Reading rights in your Library folder, this could be a Workaround. So we can configure this by our selfs. I have stored my Library on a nas, and only me can delete Files. Not roon and Not any other User or Soundsystem.