MediaMonkey 2.5.2 RC1 (build 947)
I know I have duplicate content in my library but the "Duplicate Content" node shows an empty list.
So I ran the following test: I made a copy of an .mp3 file in the same directory (that's clearly a content duplicate!), re-scanned the library (yes, the option "Analyze tracks for duplicates" is checked), then looked at the Duplicate Content node. The result: EMPTY LIST!
The 2 identical files are both in the library, if I search by title I can find both of them and they show up under Duplicate Titles, but NOT under duplicate Content.
Is this feature broken?
Files to Edit/Duplicate Content doesn't show any duplicates
Moderator: Gurus
-
SirDracula
- Posts: 40
- Joined: Tue Jan 03, 2006 1:17 am
They fixed this feature in RC1. Do both files have the same filename?
I assume that this is a bug as they should be marked as duplicates.
PS. beta related worries should be posted in the beta forum to avoid confusing newer users.
I assume that this is a bug as they should be marked as duplicates.
PS. beta related worries should be posted in the beta forum to avoid confusing newer users.
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)
He is using the RC1 so probably it's not yet totally fixed.
Probably the files have a different file name, because they are in the same directory.
Probably the files have a different file name, because they are in the same directory.
Extensions: ExternalTools, ExtractFields, SongPreviewer, LinkedTracks, CleanImport, and some other scripts (Need Help with Addons > List of All Scripts).
-
SirDracula
- Posts: 40
- Joined: Tue Jan 03, 2006 1:17 am
No, they do not have the same name (they are in the same directory).
And the feature is not fixed. I tried copying the file to a different directory, same name, different name, I can't get it to show any duplicates.
What I think is happening is that the library re-scan doesn't compute the hashes for the content, it moves through really fast. Initially none of the files in the library had any hashes, I enabled the "Analyze content for duplicates" option later on.
Still a bug?
[Moderator: please move this thread to the beta forum if you think it belongs there. Thank you and sorry for not posting there in the first place.]
And the feature is not fixed. I tried copying the file to a different directory, same name, different name, I can't get it to show any duplicates.
What I think is happening is that the library re-scan doesn't compute the hashes for the content, it moves through really fast. Initially none of the files in the library had any hashes, I enabled the "Analyze content for duplicates" option later on.
Still a bug?
[Moderator: please move this thread to the beta forum if you think it belongs there. Thank you and sorry for not posting there in the first place.]
I meant that they worked on this feature. They didn't work on your particular problem. Actually they worked on the reverse problem where too many files were shown.
Anyway MediaMonkey doesn't use tags in the duplicate content node. I believe that it calculates a hash much like p2p networks do. This seems not to work anymore in RC1.
Anyway MediaMonkey doesn't use tags in the duplicate content node. I believe that it calculates a hash much like p2p networks do. This seems not to work anymore in RC1.
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)
Duplicate content
Just tested this and it's working...sort of. i.e. if I have a clean library and scan files A and B which are identical, they will both appear in the node.
The reason it might appear not to work is that a hash is added only when a track is initially scanned into the library. i.e. if you rescan tracks after changing the settings, the hashes will not be added.
The usecase for this feature needs to be rethought, but this will be deferred beyond 2.5.2.
-Rusty
The reason it might appear not to work is that a hash is added only when a track is initially scanned into the library. i.e. if you rescan tracks after changing the settings, the hashes will not be added.
The usecase for this feature needs to be rethought, but this will be deferred beyond 2.5.2.
-Rusty
-
SirDracula
- Posts: 40
- Joined: Tue Jan 03, 2006 1:17 am