|
|
bug19083.mp4 (558,565 bytes) |
|
|
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" [OK]..[Cancel] |
|
|
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] |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
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 . |
|
|
Doc updated, KB already mentioned this possibility, Help updated to also inform about this. |
|
|
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. |
|
|
It looks like Zvezdan's script at https://www.mediamonkey.com/forum/viewtopic.php?t=102142 has already implemented much of the functionality discussed here, and could be especially useful for users who've changed the paths of files on the new drive. Nonetheless, it doesn't change the fact that the current functionality unnecessarily retains many entries in a duplicate location even when the files aren't duplicative. Would a simple low-ui solution along the following lines make sense? 1) Entries that don't have duplicates are all merged to the "correct" location 2) Entries that have duplicates in the new location aren't merged. For such files, users would use a future generic 'Duplicate files' function that has yet to be specced and in the meantime show a message: Updated %d files Unmoved files (duplicates): # (Note: only 'duplicates' isn't an existing string). |
|
|
I don't like the fact that the "merging process" is ireversible so user could do this by accident and then also Zvezdan's script wouldn't help here. If anything I think we need a kind of warning that the content of the "drives" will be merged and idealy also an option how to deal with duplicates. The problem of merging duplicates isn't only the playing data, but also references to playlists. e.g. user can have some playlists referencing the instances of duplicates from drive A and other from drive B So removing duplicates can always cause that they will missing from some playlists until it is implemented in a more precise manner by checking the playlists references before each dup removal -- which is more complex process that is rather for another beta testing cycle.. So for this cycle of MediaMonkey 2024 we could either: A) implement merging just in case there are no resulting duplicates (e.g. mirroring two smaller old drives with different folders structure into a new drive) B) Leave it as is and implement the full duplicate merging process in the next cycle |
|
|
Per discussion we probably need to: - Test how such situations arise in the first place (e.g. file monitor prior to remap? podcast download prior to remap?) - Consider that it may be desireable to retain such duplicate locations (for ease of deleting them) - Separately, implement a general duplicate management function |
- Anonymous
