View Issue Details

IDProjectCategoryView StatusLast Update
0019083MediaMonkey 5Tagging / organizing (properties / auto-tools)public2022-06-16 18:22
Reporterpeke Assigned To 
Status feedbackResolutionopen 
Product Version5.0.3 
Target Version5.1 
Summary0019083: Media Properties: Changing Media Drive letter to existing Drive letter create duplicate
DescriptionWhen changing Media Drive letter under Media Properties into existing Drive letter create duplicate media Entry in library, which can easily confuse users assuming that one entry can be deleted.

Expected :
a) that after changing/assigning drive media drive letter it is merged to existing and that Dead link search is executed to ensure what is moved and those that are found be merged to existing.
b) User can't assign drive letter that already have media entry in Library

Example: Move/copy (Windows explorer) tracks to external drive or new HDD -> Edit Media properties -> Change/select Drive with files -> entry still stays separate from new drive.
TagsNo tags attached.
Fixed in build


related to 0019087 newrusty Duplicate Manager 



2022-05-18 10:25

developer   ~0068156

bug19083.mp4 (558,565 bytes)   


2022-05-18 16:59

developer   ~0068160

Last edited: 2022-05-18 17:43

View 5 revisions

Good catch and actually it explains how the duplicate file paths can get into user library.

As for the issue with multiple drives showing under the Location subnode:
I guess this is rather desired as it still allows user to select which entry is the duplicate to be deleted.
i.e. typically if user replaces his SSD/HDD by another drive then re-assigning the drive letter (without initiating a scan of the new drive) won't create any duplicates!
The duplicates are created only if user scans the new drive before re-assigning the drive leter (for the old drive entries).

As for the possible solutions:
Probably the most desirable would be to merge the drives, but we should allow user to choose how to deal with duplicates, so a kind of warning is needed IMO.
Something like:

"Drive D:\ already contains content in your library, select how do you want to proceed: "
(o) Merge the library contents of both drives and in case of duplicates prefer entries from D:\
( ) Merge the library contents of both drives and in case of duplicates prefer entries from [Volume name]
( ) Merge the library contents of both drives and in case of duplicates use those with older date added
( ) Remove existing library entries on D:\ and use the contents from [Volume name]

Probably the wording isn't clear enough and maybe there is needlessly too many choices?
Assigned to Rusty for wording/UI suggestions.

EDIT: Another solution could be to show just warning about the lines like:
"Warning: Drive D:\ already contains library content, in case of duplicates those with older date added will be preferred"


2022-05-18 21:09

administrator   ~0068161

A couple of questions:
a) I agree with the simpler approach (or even no UI), but assuming we retain this minimal UI, shouldn't the retained entries be based on most recently updated entry (timestamp) rather than the date added or a global location selection?
b) With the minimal UI, would the retained entries reflect the combination of playlist status (i.e. if duplicates A and B are in different playlists then the retained entry should appear in both playlists) and Play counts/history (i.e. for duplicates A and B, the retained entry should have a summed playcount, and the most recently played date).

As to wording, would the following work?

Duplicate content
Duplicate database entries have been created at <Destination>.

Remove duplicates (Timestamp: oldest)?

[OK] [Cancel]

Note: the above uses only existing strings with the exception of the descriptive text "Duplicate entries have been created at <Destination>." (which would not be translated for 5.0.3). In the longer term (5.1), we could modify the strings as follows:

Duplicate content
Duplicate entries have been created at <Destination>.

Remove duplicates and retain entries with the most recent timestamp?

[OK] [Cancel]


2022-05-19 18:23

developer   ~0068173

Last edited: 2022-05-19 18:53

View 4 revisions

Note that generally it isn't predicable which of the duplicate entries should be preserved.
A working algorithm to deal with the duplicates could be: Use the entry with older date added once timesamp value is same for both entries -- otherwise prefers the entry with newer timestamp.
But even then it can happen that the older entry with older timestamp would be part of a playlist or synced to a device.
So alternativelly we could remove only those dups that are not part of a playlist (and are not synced to a device/storage), but even then it can happen that both database entries are part of another playlist etc.

I think that current situation leaving the entries on separate drives under Location node is fine as user can choose which "drive" to remove/trash. So for 5.0.3 there isn't a trivial and low risk fix, for the future versions we can add a drive merging mechanism trying to deal with the possible duplicates.

Or maybe we should just show error dialog once a user wants to assign a drive letter to a drive that is already scanned into library? This would prevent from duplicates to be created at first place.
And thus prevent from the further possible difficulties re deciding which dup entry to remove.


2022-05-19 18:59

developer   ~0068174

As a short term 5.0.3 fix we could make C:\ drive grayed out here (i.e. once a drive is already assigned to the letter).
In the future version would could rather show error/warning once the user wants to assign already assigned letter.
image.png (115,205 bytes)   
image.png (115,205 bytes)   


2022-05-19 19:09

developer   ~0068176

Last edited: 2022-05-19 19:16

View 2 revisions

As discussed offline, the above restriction would be probably too restrictive, e.g. preventing from managing content mirrored from multiple drives into single drive etc.
So I would suggest leaving it as is for 5.0.3 and then try to improve the duplicate management functionality.


2022-05-19 21:57

administrator   ~0068179

Last edited: 2022-05-19 22:25

View 2 revisions

So there are a couple of possible approaches:
1) for 5.0.4 we can use the approach described at 0019083:0068173 with the wording proposed at 0019083:0068161 . Ludek indicated that this could be problematic in the case of a deleted (non-retained) entry that is part of a playlist OR is on a sync list, however, I don't think that's an issue--it would just mean that the retained entry would appear instead in the playlist or as part of the sync list.

2) For 5.1 we can add a more general 'Dupliicate Manager' (0019087) that has long been requested that would deal with this scenario in a semi-automated fashion.

I believe there's a need for a duplicate manager, but I also think that this specific usecase can be resolved much more simply. So we'll have to decide what approach to take for 5.0.4 -- 1) light implementation or 2) defer .


2022-05-25 16:24

developer   ~0068242

Doc updated, KB already mentioned this possibility, Help updated to also inform about this.


2022-06-16 18:22

developer   ~0068566

I believe that 2) is the right solution -- solution 1) could do just more mess because:
a) it could auto-delete inadequate/undesirable duplicate
b) would make the way of identification the desired duplicate harder (as user won't no longer see files splitted into two identical drives under Location node -- to understand which files were on the original drive).

So changing target to 5.1 for the solution 2) and assigned to Rusty for spec.