I find it far easier to go to the source drive and do the deleting there. Then I know exactly what’s going on. Roon’s treatment of deletions seems a bit odd.
Last night I had to re-rip a CD because one of the tracks was corrupt and wouldn’t show up in Roon. I deleted the files on the source drive first before re-ripping and dropping the new files into that same folder. I retagged everything in MP3Tag and went back to Roon. There were now TWO instances of the album, one with three tracks, (the fourth was the corrupted one) and one with four (the newly ripped one). Both versions were playable despite the fact that the three track version had been deleted from the source drive ten minutes previously and the newly ripped tracks occupied the same folder. I used Roon to delete the old album and it warned me the files would be deleted. I decided to cut and paste the folder from the source drive to the desktop just to be safe. Roon still showed both albums and both were still playable despite the fact that the files no longer existed on the drive Roon was pointing at! I closed Roon, restarted it and, hey presto, the album was now gone. I reinstated the folder from the desktop, closed and restarted Roon at which point all was well…one album with four tracks, but what went on in the process of getting it there mystifies me!
I never understood why Roon had a delete file function anyway; everything else you can do, tagging, metadata, merging etc. is lauded as having no effect on your own files, so why allow this nuclear option? For myself, I have spent hours ripping and getting it right, and would rather not have even the possibility of losing those files (though of course I have backups).
If you really want to remove a local file from your library then use the OS to do it; and its trash/wastebasket option is then readily available,
Restrict the delete function to removing Tidal stuff from library.
Brian
In past topics, I too have suggested this to Roon as an alternative to file deletion.
-
Roon would create and support a “trash” folder in each watched location
-
When possible whole folders (all folders/files and subfolders) should be moved to “trash”
-
When this is not possible, Roon would create folders in trash, to mimic the original folder structure and then move just affected the files to the trash area (leaving the non-affected files still in place).
-
If the files already existing in “trash”, Roon could use a versioning suffix on the folder names
-
If the “trash” folder does not exist and cannot be created by Roon, Roon should advise the user to adjust share permissions or create the “trash” folder using OS tools.
As an aside, my files are on a QNAP NAS with the “trash” can functionality enabled.
When Roon deletes files the QNAP moves them to the relevant trash folder which Roon ignores.
This way if I or someone else screws up, I can recover quickly (and I have off site backups, of course).
I was thinking the “low tech” approach. Delete a file leaves it in place, but flags it as “trash”. Doesn’t appear in the roon UI unless you go to a “trash” location in the UI.
From that UI you can restore (simply removes the trash flag) or delete (removes the file as today).
I dont use the feature, other than removing Tidal content from my library. And i would rather see it reborn as a ”remove from library”-function which deletes the selected contentfrom your library, not your storage.
In my traditional use case i had Roon Server retrieve its content from a NAS share, more specifically a ReadOnly share. So then i didnt risk anything as Roon didnt have sufficient rights to delete content. Since then i have migrated to local storage on the NAS where my Roon Server is also running. Now i could delete content ifi decided to. I also have added a ROCK server which is mainly used for backup but occasinally as Roon Server where i also could delete content.
To summarize, i’d like the feature removed. Then Roon could properly state ”we dont mess with your files” without the if’s and but’s. Let users remove their content at their own risk and method.
I quite like that approach as well … like hiding but for a very specific purpose.
Then if the user removes the files using the normal OS tools, then library clean could take care of the maintenance.
And Roon Labs could say that Roon never updates, deletes or moves any files.
I guess there’s pros and cons in all options.
All of this.
No win situation.
Push me - pull you.
Who started this thread?
What a tempest in a teapot.
Aw c’mon… if you’re going to write poetry shouldn’t it rhyme? 
Haikus don’t need to rhyme and there’s a haiku in there, somewhere.
Five syllables here,
Seven more syllables there,
Are you happy now?
Why do we delete stuff?
- Don’t like the music and don’t want it to show up anymore — very important in the “attention economy”, should be handled by marking only.
- Reclaim the disk space — this is less relevant these days. A personal anecdote, for calibration purposes: when I took a job with Microsoft near the turn of the century, I was in a meeting with a bunch of Microsoft executives, talking about the evolution of hardware, and one guy said, “do you realize that there are people in this room who could buy a terabyte?” Awed silence. And now I just bought a 4 TB USB drive for $110. Size of a deck of cards, no power cord. I don’t delete. When it fills up, I’ll buy a 10 TB drive for $60.
So just a simple trash basket, with a marking in Roon, not even an “empty trash” function.
Yep, don’t underestimate the storage issue. While storage is getting a lot cheaper these days, music is still the vast majority of the storage on my drive (at least for me, but likely for any audiophile). It’s like 80 percent of my storage. I don’t really want to needless store duplicate music files I will never play.
Actually, I was pooh-poohing the cost of storage. I once did the math of comparing the cost of digital storage with storage of CD jewel cases
A CD-quality album is about 3/4 GB, high res is a bit more, and DSD albums are typically 2 GB each; I’ll make it 1 GB per album, on average. Amazon sells a 3 TB drive for $90, so that’s 3 cents per album.
What does it cost to store jewel cases? An IKEA Billy bookcase is $80, it is 31.5" (80 cm) wide, internal dimensions about 77 cm, a jewelcase is about 1 cm, six shelves, so 462 albums. But it uses floor space, 2.5 square feet, in Seattle where I live the median house price is $447 per square foot (Zillow), so the total storage cost for 462 jewelcases is $80 + 2.5 * $447 = $1,197, or $2.60 per album.
If you are concerned about disk space of Albums you don’t like, do you throw away the physical disk you ripped? Keeping that costs 100X as much.
So: if we ignore disk space, marking albums as “deleted” without any actual deletion semantics is a lot easier. (And if we actually try to delete from disk, do we delete from the backups as well? Including cloud backup.)
In fact, @mike, we already have the “hide” function. Just interpret “delete” as hide.
Or we the users can just use “hide” instead of “delete” and avoid the confirmation questions. OP problem solved.
I’d agree that the double checkbox is really annoying. Recently, I’ve been buying a bunch of special editions on CD and just ripping straight. Because I have the Old version, I want to clear the duplicates. The double check has gotten to be an irritant. Agree with the previous post that notes that most NASes will have the trashbox, or similar, or you’ll have a backup so you can recover that way.
Not the end of the world but it’s jarring an an otherwise polished product.
I think there should be an option to disable these extra steps/warnings/clicks. Even Windows allows you four levels of choice for deletion:
1: Prompt about removal -> recycle bin
2: No prompt, straight to recycle bin.
3: Prompt about permanent removal (skip recycle bin)
4: No prompt, remove permanently.
Right now it is eight(!) steps to remove an album:
1: Select object(s)
2: “Edit”
3: Scroll down to “Delete Album”
4: “Delete Album”
5: “Delete X Tracks”
6: Check “This action cannot be undone”
7: Check “These tracks…”
8: “Yes”
The most efficient solution (with a keyboard), would be:
1: Select object(s)
2: “Del”
3: (Optional prompt)
The current situation is way to inefficient, in my opinion.
Is it really that difficult to navigate to the relevant folder using your tool of choice and deleting it? For my money Roon could just as well remove all delete capability, it’s a music server, not an extension to your operating system or a file manager.
Like your proposal, but it needs to be simplified for streaming content too…
It seems to me the simplest solution to that is to delete the files from your storage directly. Not sure why Roon should do it really.
Roon takes great pains to say it doesnt touch your files at all. Why then would it have a function that made it all too easy to delete a track completely? It would be doubly misleading and no doubt cause a lot of consternation for users who accept the ‘we dont touch your files’ claim only to be caught out by the delete function, wouldnt it?
Nor me, it is against the ‘Roon will never modify or move your files’ principle that the rest of the interface follows. It is left over from when Roon did mess with your files and is just plain confusing (evidently) to some. Roon isn’t a file manager.