Looking at the reported similar topics, it’s very possible this has been brought up before. From my observations, it seems a serious issue, and people should really generate a dry-run, or run DeleteDuplicates task in “move the duplicates to a duplicates folder”, instead of deleting to see if they get the same behavior.
From the Delete Duplicates report, I’ve identified that several albums which had duplicates were aggresively cleaned up with both the original and the duplicate removed.
For the record, this is an archive I’m cleaning up for a relative. I’m software developer with crypto and professional media management and indexing experience. Anyhow. Looking at the duplicates folder I can find the original file; no harm, beside being an annoyance.
Then I wondered, perhaps the same file is in the compilations (typical). Resorting to fdupes, it did report that many dupes had their original file still in the library. But about half of them did not.
I understand that a dupe isn’t only based on the file size or hash, as the same file can be present under different quality/codecs, but in these cases, after further investigation, it appears to be really that both the original and the duplicate were moved.
Had it been a destructive operation, these files would be gone. Yes I have a backup (hey, I kinda expect those things to happen from time to time) but many clients may not.
Sorry for the noise if its a known issue. I can help further diagnose. I would be fantastic if this could work correctly.
SongKong v6.8 Rumours, docker container edition, running on Synology DS-218+.