Tackling TreeSync issues with MacKiev relying on Ancestry for answers The first sync using ‘final’ FTM 2014.1 goes badly

This is an exploration of the what and why of problems I and others have had around the sync of trees (TreeSync) using the MacKiev Family Tree Maker 2014.1 version released 31 December 2016. Some of this has been prompted by discussions on the FTM Users groups on Facebook, so thanks to the various contributors there. {1}

Update: Note that with the end of TreeSync, and the release of FTM2017/FamilySync, some of these issues will change. Our Sync FTM to Ancestry page is being updated with current info.

I have been using TreeSync since it was released in the UK, in October 2011, to sync between the family tree created using FTM software (which I use as my research base) and the Ancestry website, where invited guests can view the tree. My first attempt at a sync with the latest version was on 9th January. It has been a bit of a struggle since then to get a clearer picture of the basis of the various problems which emerged, but it has come together in the last couple of days.

Some of the following could be specific to my tree, but with luck the article might help clarify things for others encountering the same issues.

If you have encountered sync issues, the first port of call is still MacKiev’s support pages. As noted in Cutlock’s Sync FTM to Ancestry page, re MacKiev’s work on this version, they say “We have not actually touched anything to do with syncing itself in our update work. Syncing algorithms remain exactly as they were in Ancestry times. … The update is almost entirely about improvements in stability, performance and security.”

There will also be many people who will be happily using the sync on FTM 2014.1, although some of them may just be oblivious to the issues!

Problems overview

Firstly, a breakdown of the presenting problems. Relevant screenshots appear below.

1. The initial TreeSync did finish processing with no problems, although it took some time. However, many of the others posting similar symptoms on the FTM Users group on Facebook had difficulty getting to the end.
2. The obvious problem was the huge number of source citations showing in the sync stats screen and log as changed or added in Ancestry, even when only working on the tree from FTM (as I do).
3. After the sync had completed, the number of source citations recorded in FTM had increased significantly, about two thirds of the number showing in the stats screen and log as ‘changed’.
4. The Source Groups, such as ‘1841 census’ or ‘ California Divorce Index,  1966-1984’ went up in number by almost a half. The stats, log and actual result matched.
5. A number of additional media items appeared in FTM after the sync, not showing in the sync stats/log. Possibly related to the ‘added’ source citations per the logs – further investigation required.
6. Possibly specific to my tree, 3 photos which had been previously ‘private’ and not transferred from FTM to Ancestry, now got copied across.
7. Again possibly specific to the tree but less likely, two additional places appeared.

I would guess that Problem 3 to 5 are most likely to occur if you have been using Family Tree Maker for some years and solely or mainly research and collate date via FTM rather than Ancestry.

The cracks between MacKiev, FTM and Ancestry

Software MacKiev took over the Family Tree Maker software in 2016, and spent much of the year working on ironing out bugs before releasing a ‘finished’ version of its own – FTM 2014.1 – on 31st December. Previously Ancestry was responsible for FTM, FTM support and Ancestry support, so any issues around its TreeSync system (transferring data between user trees on FTM and Ancestry) had just the one place to go for resolution. Now, however, there is plenty of scope for sync problems to fall down the cracks between the two businesses. I’m not saying that has necessarily happened here, but I’m tempted.

For those who aren’t that interested, yes the lesson could well be that whatever replaces TreeSync (with luck) in the next few months should be expected to have taken these issues into account. If not, it won’t be worth whatever MacKiev charges for the new software.

Details, possible causes and solutions

Problem 1

I have always run the sync manually so I can control the timing – nowadays this is also the recommended approach rather than leaving TreeSync on auto. After logjams on the servers when TreeSync was introduced in 2011, the timing is always morning, UK time, before America is awake. This may have helped with not encountering any “hard fails” of the sync this time. I only actively sync one tree, HowesWatkinsNealScott or HWNS for short.

Syncs usually take a few minutes. Here, it was around 20 minutes the first time. The second go (see end of Problem 2) totalled about 40 minutes.

Problem 2

The Tree Sync Change Log file on first sync ran to some 648 pages! {4}

I ran the sync on 9th January only as far as the stats screen (or ‘sync change log’) as this showed figures so far outside of the expected range. (The screenshot attached is a cheat – see {Note 3}.)

On 13th January, after checking that a new FTM tree (labelled 2017HWNS, ‘restored’ from the back-up) would create a clean tree on Ancestry, I ran the sync all the way through. See Problem 2 for what this did to my HWNS tree.

Here’s a response from MacKiev’s boss on Facebook to another user with this issue (6am, 18th January):

We sent this one in to Ancestry for review and after some research they told us that the large change numbers you saw were due to some maintenance work done on their end. The bottom line is that you can just ignore those big numbers on the Sync Change Log. Only the changes you actually made will be changed on your tree. All the rest will have no effect at all.

Here’s the reply (also 18th Jan) to my support ticket to MacKiev submitted 10th January {2}:

Recently, we’ve received a number of support requests with regards to sync logs which displayed a number of changes that differed significantly from real changes made by users. As it turns out, the logs which confused Family Tree Maker users were actually the result of some server-side changes on Ancestry side.

They fixed some inconsistencies on the backend with citations, sources, and repositories. This affected citations that reference Ancestry collection data (records merged from Ancestry hints/searches). The side effect is that all persons linked to the fixed citations would be marked as changed. This will show in the FTM change log as changes to Persons, changes to Citations, changes or additions to Sources, and possibly an addition of a Repository. Even though the items have been marked as changed, no changes were made to tree data.

Unfortunately not the complete picture by any means. And, as I have indicated in Note 1 below, it is an issue that has apparently been seen before. Did Ancestry not remember or not bother to pass on the info to MacKiev until users got hit?

Problem 3

The changes in the FTM tree can most easily be seen by comparing before (left) and after (below) screenshots.

Citations have gone up by 6,511, rather than the logged ‘changed’ number of 9502 {3}. An extra 153 Sources (or ‘Source Groups’) can be seen.

The MacKiev support FAQ ‘Family Tree Maker compared to Ancestry trees when using TreeSync‘ has this statement:

• Family Tree Maker and Ancestry handle source citations differently. Family Tree Maker allows a single citation to be linked to facts from multiple people whereas the online tree system restricts a single citation to a single person.
• When a tree is uploaded from Family Tree Maker to Ancestry, the resulting tree on Ancestry will replicate citations that are shared with multiple people in Family Tree Maker so that each person has their own citation on Ancestry. If the tree is downloaded as a new tree in Family Tree Maker, that replication will be in the resulting Family Tree Maker tree as well.

As previously explained, this is not a ‘new’ FTM tree, and the conversion from FTM 2014 to FTM 2014.1 was of the existing tree file, not a copy (unticked the default). But perhaps the conversion confused the sync system to some extent, and the Ancestry changes outlined under Problem 2 are then being processed as if my existing tree was new.

Problem 4

The Source Group position does correspond with the MacKiev answer under Problem 2. But it leaves a mess. These screen shots only give a rough idea of what is going on at an individual source/citation level.

 

 

For me, the mess is doubly annoying as I did quite a bit of tidying up of media, sources, etc, in the autumn.

I cannot currently see a logic to which Source Groups got changed and which didn’t. This worries me particularly given the support answer under Problem 2: “They fixed some inconsistencies on the backend”. Perhaps they will fix more in the future and we will have another such episode.

Some of the original Source Groups on first sight seem to still have citations attached. However, as per this screen grab focused on the Source Management dialogue box and its break-out of (original) ‘1871 England Census’ source group, there are no longer any person links from such citations. Underneath is the empty Link tab of one such citation.

Repositories, in case you were wondering, are where sources are located. In this case, Ancestry.com was added as ‘new’, although it already existed, as do www.ancestry.com, www.ancestry.co.uk and Ancestry.co.uk – all variations on saying that the source is part of the website’s massive database of records, transcriptions etc. These repository variations were in the original FTM tree, and they also show in the new one created as a test.

Problem 5

As I categorise all media in Family Tree Maker before I run a sync, the interloping media from Ancestry were obvious. They are also evident from the date stamps on browsing the HWNS Media folder in the computer’s file directory. The nine in order they appear in the Media library:

• 1891 Census, attached to separate citations for Harriet James (2 facts), John William James (1 fact). Is duplicate: two original citations attached to 7 facts.
• 1901 Census, attached to 1 citation for Nellie Streeter, 1 fact: female. Is duplicate: original citation is attached to 4 facts.
• 1901 census, 1 citations for John James, 1 fact: male. Is duplicate: original attached to 4 facts.
• British Phone Book, citation for Stanley J Cullum, no fact. Restored uninvited: original media (and citation) had been deleted from FTM not long before, but prior to the final FTM 2014 sync.
• Birth Index FreeBMD, citation Nellie Streeter, 1 fact: birth. Is duplicate: original attached to 2 facts.
• Birth Index FreeBMD, citation Elsie Vera Marsh, 1 fact: name. Is duplicate:  original attached to 2 facts.
• Death Index, citation George W Leese, 1 fact: birth. Is duplicate: original attached to 3 facts.
• Death Index, citation for Harriet James, 1 fact: birth. Is duplicate: original attached to 3 facts.
• Marriage Index, citation for Keith Ratcliffe and Wendy Liddiard, 4 facts: marriage/name. Is duplicate: original also attached to 4 facts.

Apart from the first and last of those, the duplicates and originals are each attached to only 1 person’s facts. A total of 13 citations added to facts, which equates with the log.

It is noticeable that all except the Phone Book are for people in one particular branch of the family (nephew’s in-laws). Therefore it is possible that the original citations/media may well all have been added at about the same time, some years ago (he married in 2010).

There was a slight difference in how two of the media were restored in second sync – the phone book and marriage items show a date/ time stamp corresponding to the last sync using FTM 2014, rather than that of this sync.

The added media (9) and citations (13) shouldn’t be hard to remove, but it is worrying not having any idea why these were duplicated in the first place.

Problem 6

Three FTM added media items appeared in the second go at the sync {note 3}. These were attached to facts (not Ancestry sourced) which had been marked as private in FTM, and previously had not sync’d across to Ancestry. The photos were added while using FTM 2012, the first version to have sync, and I think it was happy with that setting. FTM 2014 seems to need to have the actual media item marked as private, but this had not bothered the sync since I installed that version in February 2015.

The reason why the 3 photos were triggered this time could be because of ‘new tree syndrome’ or some tweak in FTM 2014.1.

Easily fixed by changing the privacy settings in the tree, and unlikely to occur again.

Problem 7

Both repeated place names were from the 2 tree changes made during the couple of days between the last sync using FTM 2014 and the conversion to 2014.1. These were part of the ‘Resolve Conflicts’ part of the sync process {3}.

I have encountered place names being spuriously repeated before. (Once or twice, two separate places became one and it took some ingenuity to re-separate them!) Whether this was after a sync I can’t remember, but it does mean that I check the Places index frequently. (I don’t use the ‘resolve places’ feature.)

Again, easily fixed with a little care. First, locate the connected facts via the Places index, then change the repeat place name – for instance from ‘Wales’ to ‘Wales NOT’. Go to the connected fact and change the place name to the correct one.

Could this happen again when more facts are added on FTM?

Conclusions

It is still possible that the various outstanding problems can be resolved in some way. The following is therefore an interim view.

There would seem to be no real user advantage in updating to the MacKiev 2014.1 at this point, particularly if your research and tree building is done largely via FTM and your current version is working for you. There is only one minor new feature (password protection on export). Instead, it would seem sensible to wait until the next version, with the replacement for the TreeSync feature, once that replacement has been fully tested.

Personally, the extent of the obvious changes and the unknown nature of what might be lurking behind them means that moving over to my already created new 2017HWNS tree seems safest. However, the original HWNS tree, which had (until now) only minor sync problems since December 2011 when FTM 2012’s initial bugs were ironed out, has 30 guests invited to the private tree online and almost 16,000 outstanding Ancestry hints were cleaned out just a few months ago. It will be a nuisance having to wade through those thousands of hints again as they gradually reappear. Some of my older tree guests might also be rather upset after earlier struggles in getting tree invites through to them.

If the precise nature and process of the source/citation changes by Ancestry can be identified then perhaps cleaning up the Source Group mess could be a viable alternative.

Other FTM users may have different tolerances on uninvited tree changes.

Notes

There is a little more tidying to do on this article. Please do give your comments and suggestions on the issues via the comments (or contact form if you prefer) – hopefully usefulness can be improved too.

1. Re Facebook FTM Users Group, particular thanks to Bob Shalvoy for floating the Ancestry to FTM citation splitting issue. And thanks to Shirley Kelly for explaining why she thought that Problem 2 had been seen (more than once) before: “The first time I experienced it was after the beta testing of the original release of 2014“.
2. A second MacKiev support email arrived as I pressed the publish button for this piece, after supplying further details – “information (forwarded) to our engineers for further investigation”. A third on 23rd January askign for a little more info on a couple of points – my answer included referencing this article (Problem 5 details, screen shots).
3. Both the stats screen and ‘FTM stats after’ screenshots are a slight cheat as they weren’t ‘grabbed’ first time round. I was so disgusted with the state of the HWNS tree after the first 2014.1 sync that I pretty soon restored it from back-up. I re-ran the sync on 19th January so that I could investigate the issues further, after MacKiev’s initial answer.  There weren’t any changes from FTM to Ancestry first time round – the 1439 People changes appears to be purely for Notes, and the media items are discussed under Problem 6. The number of Ancestry citations logged as ‘changed’ was previously 9510 not 9502, and the resulting figure in FTM was 18,383 not 18,379. In addition the ‘Resolve Conflicts’ appeared before getting to the stats screen, with 18 items as below (the next screen showed 2 people and 14 citations needing review, hm doesn’t add up to 18) – all resolved by taking the FTM data.

   

   There had also been one media item added on Ancestry, which I recognised and was happy to ignore as an issue.

4. I have kept all sync log files, and the next largest is for the conversion of HWNS tree from FTM 2012 to version 2014, in February 2015 when there were just 130 fewer people in the tree. 142 pages, all FTM changes to Ancestry, 466 media, 4 repositories, 134 sources, 2,267 citations. I wasn’t an early adopter of FTM 2014, which was released autumn 2013 with minor new features and 2012 sync had been working well for me.
5. Also see Sync FTM to Ancestry page.