4 replies to this topic

[TomH]

Given an Ancestry Source already tagged to a fact on my Ancestry Member Tree which has been TreeShare downloaded to a new database. Add that Ancestry Source to another fact and Accept that change. TreeShare downloads the image file again and repeats its name in parentheses. Now the media folder has the same image twice with two names and the RM Media Gallery shows them both.

 

Do it again. This time, it appears that the image may be downloaded again but it might not. Either way, there remains the two images in the folder, "name.jpg" and "name (name).jpg". However, the Media Gallery now shows 3. That's because the MultiMediaTable has three records for the same image. For example:

 

MediaID MediaFile

1 40356_320214636_0045-00433.jpg

4 40356_320214636_0045-00433 (40356_320214636_0045-00433).jpg

5 40356_320214636_0045-00433 (40356_320214636_0045-00433).jpg

 

So citation media files are at least duplicated and, in the Media Gallery, they multiply like rabbits. And there's no Merge tool for media.

[mjashby]

Yes, I've also found this to be 'standard behaviour' when using TreeShare to download the 'same' fact to a number of individuals, e.g. Census data. Also reported it a number of times during the Testing Phase, but never saw any acknowledgement or improvement.  I was preparing to report this on the Forum together with a few other quirks (see below) but you beat me to it.

 

At present, the only option (other than allowing the continuous proliferation of duplicate media) seems to be to keep a regular keep watch on the media folder, delete the duplicates, and then manually 'correct' media tags/links.  

 

The occurrence of duplicate media can be reduced, but again only (at present) through manual intervention, e.g. when you know that a fact/source media downloaded affects a number of individuals e.g. a Census Record, add the entry to the other individuals and use Memorise and Paste to add the Source(s).  However, I've found that some of these additions also require some editing of Source Detail, e.g. for Ancestry Source records that do not identify a Family Relationship  (Census Records/Passenger Lists etc,) the "Source Details" often include a different line number for each individual on the image page which makes every citation for that image different. There is a similar issue where multiple families of interest appear on the same Census Page.

 

Must admit that I experienced the same issue from time to time with the 'OId' Ancestry Sync procedure, so was aware of the potential for this problem. Not sure if FTM 2017 suffers in the same way as I haven't tested.  I suppose the main issue is to understand whether this is a current limitation of the API, or if there is any way for RM to check and warn users of 'apparent' duplicate media. - It would, presumably, be considered poor practice to simply overwrite existing media with the same file name, as they may not be identical images, hence the image file names are altered whilst ensuring that the image files remain in a logical sequence, thus highlighting the problem.

 

Additional Duplication/Other Issues:

 

 - Duplicate Ancestry Sources appearing in the Master Source List - These cannot always be cleared with 'Automerge' so often have to be merged manually.

 - Place List needs constant attention/management/pruning because of the multiple ways Places are recorded in Ancestry's data sources.

 - Data drawn into RootsMagic from the Ancestry Fact Description Field may be visually useful, but make little sense in RootsMagic reports when left 'as is'.

 

Mervyn

[Jerry Bryan]

It would, presumably, be considered poor practice to simply overwrite existing media with the same file name, as they may not be identical images, hence the image file names are altered whilst ensuring that the image files remain in a logical sequence, thus highlighting the problem.

 

Actually, normal RM processing without TreeShare deals with this issue somewhat differently. Suppose you already have a media file in RM that is linked to some object in RM. The "linking" is called tagging, and there two ways to tag a media to an object in RM. 

 

In the new way of tagging, you start with a media file that's already in RM and you tag the media file to the object, where the object can be something such as a person or a fact or a source or a citation or a place. Doing the tagging in this direction, everything works in a a completely straightforward fashion. The existing media file is simply tagged to an additional object in addition to any other objects to which it was tagged and no duplicate media files appear as a result.

 

In the old way of tagging, you start with an object and link in the media file. There are then two separate cases. In the first case, the media file is already in RM. If the media file is already in RM, it will be in the Media Gallery. So you start with the object and select the file from the Media Gallery which you wish to link to the object. If the media file is not already in RM, then you start with the object and select the file from a Windows folder. RM  opens a standard Windows File->Open type of dialog. You will have to know where the file is on your computer so you can navigate to it and select it. 

 

But there is a secret case number three. The media file can already be in the Media Gallery and nevertheless you can select the file from a Windows folder. You might do so by accident because you didn't remember that the file was already in the Media Gallery, or you might even do so on purpose. If you link in a media file from a Windows folder even though the file is already in the Media Gallery, then there is no warning and the newly selected file from the Windows folder replaces the file in the Media Gallery. Again, you might be doing this by accident or on purpose. There is no duplication of media files as occurs with TreeShare, but the results might not be what you expect. Well, for the current object, the media file that you just linked in is probably the one you expect, but you might unwittingly be changing the media file for other objects that were already linked to a media file of the same name. The other media file of the same name might or might not be an identical copy of the same media file.

 

I'm not quite sure what RM's "standard" processing for duplicate media files might suggest for TreeShare. I think it suggests that TreeShare ought not to make duplicates, but whether it should retain the original or replace the original with the new copy I'm not so sure about. In theory, the two copies should be identical. But if RM warned you and asked you which copy to keep, that would surely aggravate even further the onerous nature of doing bulk update operations with TreeShare.

 

Mac users will have to translate the Windows operations I described into their Mac equivalent.

 

Jerry

[Renee Zamora]

In WebHints and TreeShare if you mark all the facts you wish to update that have that media it will bring in only one copy when you click "Accept Changes". If you "Accept Changes" on individual facts one at a time it will consider them new images with the same name. That is why you get duplicates. 

[mjashby]

Renee,

 

What you say is correct; and that can be managed by the user within the TreeShare actions available once one realises the implications. However, you also get duplicate media downloaded when you synchronise the same facts for other individuals, which link to the same Source and Media file, which is not user manageable in TreeShare as things stand.  

 

A typical example is Census  Facts and Media (or Residence Facts in Ancestry Terms) which apply to a whole family already in the RootsMagic database, or to multiple families shown on the same census page.  The only way I've found to prevent this duplication is to draw in the Census Fact and Media for just one individual and then manually enter the Fact and Memorise/Copy the Citation all other individuals on same the Census Page that need to be linked to that Fact, which an effective manual synchronisation process but not an efficient one.

 

Mervyn