Digging into RM9’s reported naughty behaviour in allowing the same media file to be attached or linked to a database multiple times, I’ve discovered that to be not wholly the case and, on top of which, the outcome of Restore with media from Backup with media lost one of five links to media in a small test case.
The test involved two media files having the same name (One.jpg) but different content (graphic 1 or 2) in four different locations. The “1” file was in the designated Media folder and was linked twice to the database (as per the preceding discussion) while the “2” file was copied to the root of the user Documents folder, to a “…_media” folder as might be expected from a TreeShare download or a Restore with media and to a Google Drive folder. This is how they appear in a SQLite query of the database and in the Media Gallery.
MediaID
MediaPath
MediaFile
Caption
1
G:\My Drive\Temp
One.jpg
Drop to Gallery G:\My Drive\Temp\One.jpg
2
~\Documents
One.jpg
Drop to Gallery C:\Users\Tom\Documents\One.jpg
3
?
One.jpg
Drop to gallery C:\Users\Tom\Documents\FamilyTree\RM9\Media\One.jpg
4
*\MediaTest_media
One.jpg
Drop to Gallery C:\Users\Tom\Documents\FamilyTree\RM9\MediaTest_media\One.jpg
5
?
One.jpg
via Edit Person> Fact> Add New media>browse (Drop prevented a duplicate)
I filled the caption field with the expanded full path to the file to keep track in the Backup and Restore with media that follows.
Note that the Drag’n’Drop method of adding new media precluded linking the same file twice (as I believe should be the case) but I was able to do so via the process of browsing to select a file as “new media”. And that allowed a different caption for that link to a file that was already linked (MediaID=3). However, Database Properties falsely reports 5 Media Items when there are only 4 media objects linked to the database.
The story gets murkier when the database is replaced by a Backup and Restore with media operation.
MediaID
MediaPath
MediaFile
Caption
1
?
One.jpg (2).jpg
Drop to Gallery G:\My Drive\Temp\One.jpg
2
?
One.jpg (3).jpg
Drop to Gallery C:\Users\Tom\Documents\One.jpg
3
?
One.jpg (4).jpg
Drop to gallery C:\Users\Tom\Documents\FamilyTree\RM9\Media\One.jpg
4
?
One.jpg (5).jpg
Drop to Gallery C:\Users\Tom\Documents\FamilyTree\RM9\MediaTest_media\One.jpg
5
?
One.jpg (6).jpg
via Edit Person> Fact> Add New media>browse (Drop prevented a duplicate)
All filenames with extensions are assigned a serial number starting at (2) followed by the repeated extension.
All files have gone to the Folder setting for media, not a sub-folder having the name of the database file appended with “_media”.
One of the files (One.jpg(6).jpg) failed to be created and there is now a broken link. Notably, that was the second link to the original One.jpg in the same folder.
Therefore, RM9 is confused whether it allows or disallows multiple links to the same file and that needs to be addressed. And I would reiterate that the proper way is:
Only allow a file to be linked once
Support a ‘master’ metadata set (caption, description, location…) per file that is the default for each tag
Return to custom metadata at the tag level (RM4) which overrides the ‘default’
New: revise the structure to parallel that of Citations in which ‘uses’ have been split from the data: interpose between the MultimediaTable and MediaLinkTable a MediaMetadataTable for the custom metadata.
custom cropping which the database structure also supports and did from RM4 (and maybe earlier) should also be at the tag level to respect the one file-one link to database rule while allowing multiple crops from the same image file.
empower media management to support duplicate search and merging, extending from duplicate file names in different paths, file size, image data independent of metadata, image comparison (even the RM generated thumbnails might be a good enough basis)…
Support the reading and writing of master metadata from/to the linked files emebedded metadata.
I’ve not experienced an issue with that. Why do you suggest it? One thing I did note is that the MultimediaTable has been defined with the filename collated with RMNOCASE but the pathname is implicit, therefore the default which I guess is NOCASE.
I caused a second such duplicate link to the One.jpg using the Add New Media dialog on the Media main view and the result of the Backup-Restore with media was that both such links are now broken. So there is clearly a trap for users when they Add New Media via other than Drag’n’Drop and mistakenly select a file that has already been added. The trap is that those duplicate “Adds” will be broken after a Restore with media and Fix Broken Media Links cannot help because the serial numbered file never got created. Each one will have to be edited to point to a file that is believed to be the original from which the duplicate links were made.
Outstanding work. There are so many foibles here I can’t really get my head around all of them at the same time.
Nobody will believe me, but I’m just a simple country boy. So I try to be very simple when I’m linking media files into RM9.
I don’t use TreeShare to download media from Ancestry.
I don’t drop media files into RM9.
The only way I introduce media files into RM9 is via Add New Media to a specific RM9 object such as a citation or fact. I do not introduce a new media file into the overall RM media gallery without linking the file to an RM9 object at the same time. I navigate to the media file from within RM which has the effect of using the standard Windows File => Open dialog.
I only do Add New Media File for one media file at a time and only for a media file that I have just created so that it can’t possibly exist already in RM9.
I add additional media links for the same media file only by doing Select Existing Media to a specific RM9 object such as a citation or a fact. Prior to doing the Select Existing Media, I will have memorized to the Windows clipboard the name of the media file so that I can paste it into the search box in the media dialog.
That’s a lot of somewhat artificial restrictions I have placed on myself. But it was the only set of workflows I could figure out for RM8 (and now for RM9) that seemed both safe and reasonably easy to do. I’m not 100% sure but I think that my personal media workflows for RM8 and RM9 will avoid most or all of the foibles you have pointed out.
My media workflows for RM8 and RM9 are radically different than my media workflows were for RM7. So I certainly don’t insist that RM8 and RM9 be “just like RM7” and I’m much more flexible than some people probably think I am. Therefore I will only comment further that I think there are some traps in media management for RM8 and RM9 that weren’t there in RM7. The restrictions I imposed on myself in managing media in RM8 and RM9 are what are what works for me and what seems safe to me.
This is not a big deal and can be imposed at the database design level. I’ve tested it and it works with some pitfalls because RM does not trap the SQLite error message when a duplicate link is attempted:
RM does not crash and Add New Media in the main Media view now behaves the same as Drag’n’Drop did before the modification when the file was already linked - nothing amiss is reported but no new link is created. From the Edit Person window, Add New Media reports no error but the preview is empty as the link to the file was not added but a Tag has been created and the fact list shows the presence of media. The tag has to be deleted to clear the false indicator.
So developers could readily add the constraint to the MultimediaTable and should also trap the error message already coming from Drag’n’Drop new media along with the new error message resulting from the constraint so the user is informed and false tags are not created.
The change I made to the MultimediaTable was to add the UNIQUE constraint:
Found this thread as it relates issue my friend was experiences. @rzamor1
I did not see response – have Tom’s “suggestions” been passed to developers?
Only allow a file to be linked once (edit: amplified in this comment)
Support a ‘master’ metadata set (caption, description, location…) per file that is the default for each tag
mpower media management to support duplicate search and merging, extending from duplicate file names in different paths, file size, image data independent of metadata, image comparison (even the RM generated thumbnails might be a good enough basis)…
Support the reading and writing of master metadata from/to the linked files emebedded metadata.
