When Tom speaks, I listen. So I double checked just now to be sure I’m not a completely crazy person. Namely, I just now added a “new” media file to a fact in RM7 where the file was already linked to RM7. Without me doing anything to make it happen, RM7 added the file to the fact as a new media tag and without adding a new media file.
Just be extra cautious, I repeated the experiment in RM9 and RM9 did create a duplicate media file as we have been discussing in this thread. I used the same fact for the same person and the same media file in both experiments.
To be all technical and databasey about it, RM7 did not add a new row to MultimediaTable. It did add a new row to MediaLinkTable which linked the existing row for the file in MultimediaTable to the fact (the link to the fact is the media tag).
RM9 did add a new row to MultimediaTable and also a new row to MediaLinkTable which linked the new row for the file in MultiMediaTable to the fact (th link to the fact is the media tag).
Tom is certainly correct that there is nothing in RM7’s table definition that prevents a duplicate file from being entered. So the constraint has to be in the RM7 app rather than in the RM7 database. I can’t remember for sure, but I think that when the change was made in RM5, I tried and failed to enter the same media file twice so that I could give each instance of the file a different caption. That didn’t work and I had already lost my captions anyway, so I gave up on using captions in RM.
Yes It seems if DragNDrop is NOT used in RM 9 it will create duplicates. This might be by design. However, that detail is NOT mentioned in the from what I saw in the WIKI documentation-- that adding duplicate media file records is possible and caution should be advised and drag n drop will not. The need for more than one caption seems be a likely reason. I have not yet replicated the exact issue CSB has – where items in the Multimedia Table are not displaying in Gallery.
I suspect the allowing duplicate media will lead to confusion to many users… some might have one tag, other manys while some will have Zero tag… and then a person could remove the wrong file or add tag to wrong version etc.
From RM5 to RM7 (don’t know about RM8), Add New Media allowed only unique combinations of path and name for media items to be added to the Gallery.
There is a peculiar boundary condition in RM9 that you should pass on and that is that after a media item has been deleted from the Gallery, it cannot be added back in by drag’n’drop. Now I have not tested this after closing and reopening the database - it’s possible that a new session would clear the condition. It occurred during testing of how duplicates might be created through the UI.
Add New Media, however, treated it as new. So, in the process of restoring the software constraint to prevent duplicate links to a media file to the Add New Media function, be sure to test for and correct this boundary condition which might propagate from drag’n’drop.
it probably should not be add new Media if it is going to add duplicates that is grossly misleading in my opinion. Also there should definitely be a tool Merge Duplicate media to fix the duplicates if when they occur (similar to how to the merge duplicate citations & sources work)
One other thought on this – since "ADD NEW MEDIA " apparently can and will add duplicates which appears to be the databases is configured and does not prevent duplicates. It is unlikely a change would implemented to correct for this “design” as it would break many users existing databases (at least not before RM 10). Since it is way to easy for user to add duplicate – there is a real need to merge duplicate media. Since I do media differently this is not something I need personally. however I am advocating for other users. Also I believe the wiki and other documentation needs to be more clear on duplicates can be easily created which might lead to much confusion when attaching and managing media. @rzamor1
It’s interesting to find out there was, or is anything in place to control duplication. I have hundreds of duplicate media entries, most created by TreeShare. These go back to initial use of RM when it was first released with TreeShare. I would love a cleanup function.
If you only add media via Drag-n-drop you should NOT end up with with duplicates.(even when media already exists)
You can use Drag-n-drop to add additional tags with creating duplicates.
Any Time you use “add new media” it can/will create duplicates (and does not warn you) when Media File already exists.
As far as Tree Share – I do not use Tree Share Ancestry to RM – so I have not witnessed that.
What is really needed and other have asked for – is a Media Cleanup tool to merge duplicates with advanced features
I could be wrong, but I suspect the need could be more subtle than that. For example, what if there were duplicate media files in the vein of same file name and a different file path. Should they be merged? Or what if there were duplicate media files in the vein of same file name and same file path and a different caption. Should they be merged? And how should the Backup With Media function work, given that it collapses all files into the same folder?
I’m totally agreeing that this is an important problem to be solved. But I’m no longer sure that a tool to merge duplicate files is the total solution. It’s probably part of a bigger solution. But the Backup With Media function really complicates things if the duplicate file names exist in different folders or if the duplicate file names have different captions.
you raise a good point about backup with media option – adds additional problems – I had not considered that as I never used that option (nor am I ever likely to). I prefer to backup my media using external drives and cloud storage separately
Yes I agree – this make the “solution” more complicated that any one solution. Since the database allows for duplicates and is not restricted apparently by path/file (as one might expect) the need for backwards compatibility is needed to no break existing users use of duplicate (either intentionally or unknowingly). Simply adding the unique constraint now would break many users use thereof, despite prevent future duplicates. The wiki and documentation need to be clear of how/when/if duplicate can be created