Clean Up Library should list the "deleted" files it proposes to remove

Feedback Feature Suggestions
#57

There’s no need to compare resumes and I think we’d all do well by not assuming where ours ranks among the others in this thread. This is not a complicated feature request and is clearly possible to accomplish within the existing framework of the Roon database.

Again, this is really very simple:

  1. How does Roon know that a track in the database needs to be cleaned?
  2. What does Roon know about a track in the database that needs to be cleaned?
  3. Is there information about a track in the database that needs to be cleaned which Roon knows but does not currently display to the user?
  4. What is removed from the database once a user cleans it?

Answer those four questions and I think you’ll be aligned with the thread. This request relates only to item 3.

Please believe me when I say: If you think this then you are misunderstanding the request. Truly and honestly. I don’t know how to say it more clearly.

#58

Sorry, but logic is missing from your argument. First, I never implied that hexadecimal was a way to reduce the size of the index. I just used hexadecimal is an example as it has been used in computers since I started taking computer science in 1969. That in no way implies that hexadecimal is the only way, or even the best way, or doing it. If a file magically reappears, it was never “lost”, but just reindexed to express it’s new location.

“Once a file is deleted, Roon no longer needs any information but the file location / index”…Huh?? Nothing you said after that has one iota to do with my comment. I never said or implied anything to do with misconfigurations or permissions. I said DELETED files. Regarding Qobuz and Tidal files disappearing, through 1.7, such files showed “unavailable” in the tracks list. Whether there is a better way to do that, I don’t know. That is why I didn’t broach upon that. Without knowing all about the inter-platform intricacies, it’s anybody’s guess on that.

“Once the user performs the “Clean up Library” process, the entry is removed entirely. Metadata and any index. Everything. There is no step in this process where the information about the track is removed yet, curiously, an “index” of the record is kept. There would be no value to that to anyone.”…Excuse me?? Virtually everyone would benefit, as Roon would run slower having to retain all that information than if it only has to retain the index (file location). Again, all I have said pertains to DELETED files. Not once have I said it implies to group 2 or 3.

#59

Which of this statements do you think is incorrect? Speaking of the screenshot from mikeb above:

  1. Roon is aware of 41 songs in its database which reference files which the server can no longer find on disk
  2. Roon’s database contains all the usual metadata about those 41 songs: artist, track name, file location, etc.
  3. The “Clean Library” function informs the user that 41 such songs exist in the database.
  4. If the user chooses to clean the library, those 41 database records will be deleted.
  5. If the user has not yet run “clean library” and 1 of those files somehow re-appears on disk (because its absence was transient or the result of a misconfiguration) that song will no longer need to be cleaned and the corresponding count will drop from 41 to 40.

Do you agree that all of these statements are accurate?

If yes – then this feature request is simply to amend number 3 and allow the user to inspect the entire database entry for those 41 songs and not just be told how many of them there are. There is no performance impact to this change, it is simply an addition to the user interface.

#60

  1. How does Roon know that a track in the database needs to be cleaned?..By an index number without any attached data, in all likelihood IF the tracks are in the first group.

  2. What does Roon know about a track in the database that needs to be cleaned?.. if it’s group 1, hopefully NOTHING except it’s index / location. Anything else is BLOAT!!

  3. Sometimes. My Christmas tracks only show from 12/1 thru 12/26, as they reside on a dedicated drive disabled the rest of the year.

  4. All data plus associated indices.

Remember, the more data a software has to keep track of, the slower it gets. Definitely a case of less being more performance.

#61
  1. I bet this is wrong if you deleted the song via Roon, in which case, I bet only the index survives, (Group 1)
  2. With group 1, I bet the index only remains in the database.
  3. We know the indices will be deleted. anything else is conjecture.
  4. Only applies to group 2 & 3. A deleted song will not miraculously reappear.
#62

This cannot be correct and it’s easy to test if you don’t believe me.

Roon stores quite a bit of information about a track in the database. You’re able to override the track name, artist name, your metadata preferences, and add tags to each track in the database. These edits that you perform are stored in the Roon database, they’re not contained in the underlying file.

Imagine you have a track in your Roon database and you fix a misspelling in the track name, and you make a few “Prefer file” or “Prefer Roon” adjustments to the metadata preferences. And you add a few tags. All that is stored in the Roon database.

Now, delete the file from disk or move it to another location that Roon cannot see. I don’t mean deleting the track from Roon, but the actual file on disk.

This is now a entry that needs to be cleaned. Roon will report that there’s 1 song that needs to be cleaned.

Your view is that at this point, there is nothing in the Roon database except an index number and the full path to the file, right?

Now undelete the file, or move it back into place. Guess what? All of those edits and tags are still there. Why? Because they exist in the Roon database. This is why the Clean up Library feature exists. Because you’re right, all that data takes up space in the database and if we know for sure that the file is never coming back then it’s best to delete the entry in the database.

But sometimes that file is missing for other reasons. And we do expect it can come back (like your Christmas songs). Or if the file is missing because of a technical problem that can be resolved (like a NAS that’s offline). In those cases we absolutely do not want to clean those entires from the library because we’d lose play counts and tags and metadata edits. If we clean those entries and then the file comes back, we would experience the loss of that data.

Because of this, it would be really great if Roon would provide more information about what songs it is seeing. Because that information could lead to finding and correcting whatever problem has led to the file not being visible to Roon where it expects the file to live.

Do you understand now?

#63

I think perhaps I didn’t explain this clearly before. If you delete the song via Roon there is no reason for an index to survive because the index contains nothing of value. That’s what I meant when I said there was no value to the user to have an index without any of the other data about a track.

If you delete a track via Roon I’m sure it deletes everything including any index. There’s no advantage to keeping the index in that circumstance.

This is not true. A “deleted” song might not actually be deleted. It might be on a USB drive that has lost power. Or it might be on a NAS but the file sharing permissions have been changed and Roon can no longer read the directory on that mounted volume. Or the operating system might have a new bug that gets confused when it encounters filenames with umlauts. There are a near infinite number of reasons why Roon might no longer be able to see a file it expects to see which are transient problems outside of Roon’s control and can be remedied by the user, restoring Roon’s ability to see the file.

#64

If it reappears, it’s either group 2 or group 3. Group 1 won’t reappear, with the possible exception if Tidal or Qobuz puts a song back into their system with the exact pointers all the same. I have never seen this happen, but I can’t say that’s impossible. Many times I have deleted songs from my library, and group 1 has correspondingly increased.

#65

This is not correct but I’ve run out of ways to explain it. Best of luck to you.

#66

That is what I have always had happen through 1.7. But, just now, I moved something off my watched drives, and to my bewilderment, it showed up in group 1. Prior, it always went into group 2. (Something I pay close attention to as I’m a total computer nerd). Sure hope I don’t have to relearn everything. But at least I haven’t seen the 1.8 iPadOS crashes (yet) that so many have.

#67

I just had 611 songs deleted from my library, that seems to be like an entire catalogue that just has gone missing now … I do have 2900 albums in my library, so sooner or later I might find out, what has been deleted, but maybe not…

as a collector, this is really something that begins to bother me … but then streaming and collecting might just not go together

#68

+1 on this one

Roon dev team - please please!

#69

Have you voted using the Vote button at the top of the thread? Just adding a “+1” post will not sway the Roonies…

#70

Nope, but have now!

1 Like
Monitoring of TIDAL / QOBUZ album disappearance from library with provision of corresponding alarms
#71

2 posts were split to a new topic: Favorite album disappears from library

#72

I just voted for this.
I would like to clean up my library, but I sure would like to see a list of what has been affected. 1712 deleted files is a lot, and if there is something on my end that needs to be addressed, I want to know. I know my library better than anyone. A visual scan of a list would allow me to feel confident in cleaning up those files.

And 70 files that are associated with disabled storage locations? I certainly would like to see a list of this. It could tell me what might be wrong… or not.

They provide a list of skipped files, and it even provides a reason it was skipped. Easy. A quick scan of that list tells me what I need to do with those files and where those files reside.

I don’t understand the blowback and bickering associated with this request.

Screen Shot 2022-04-10 at 9.17.34 AM
Screen Shot 2022-04-10 at 9.17.34 AM1388×820 120 KB

2 Likes
#73

It’s quite a shock when there’s a big number to “clean up”, and there’s no indication why.

Me neither. It really seems simple and clear enough.

1 Like
#74

I guess if there will not be a way to monitor what needs to be cleaned up, perhaps it should be cleaned up behind the scenes by Roon so we don’t even know it is being done. The current approach is an in-between user control/awareness that isn’t really effective. It implies a level of control that really isn’t there. So either offer more information (and thus control) or remove it entirely and perform these tasks behind the scenes. I would much prefer the former.

6 Likes
#75

Wow I have never used this feature and sure enough I had 1500 files for removal. I would really like to know what those were, I dont have a terrific amount of tidal downloaded so it may be an issue in my library somewhere.

1 Like
#76

A real-world example:

I accidentally deleted a folder from local storage and recovered it from backup. However, the backup was quite old, so I know I’m missing some more recent rips. It would be nice if Roon could tell me what rips I’m missing. (That would be easier than to look at my pile of most recent CDs that aren’t categorized yet)

1 Like