Problem with treeshare using new Ancestry API

I have now several times had a problem of changes in Ancestry not reliably being reflected in Treeshare.

My main tree has just over 67,000 people. I principally use Ancestry, update my tree there and update a copy in RM with treeshare; all my changes therefore pass from Ancestry to RM. I only updated from RM10 to RM11 when the new Ancestry API required it.

Not surprisingly, treeshare took some time (about 90 minutes) to run the first time; having recently had comms problems with treeshare, I was pleasantly surprised that it finished correctly.

However, it was immediately clear that treeshare was not showing onchanged all people I had recently worked . I took this as a one-off problem, having updated RM, converted a file and started with the new API. More surprisingly, some of the people not initially shown as changed did show as changed when I next ran treeshare, even though I had not worked on them again.

I have since had similar problems several times, most notably yesterday evening. I recently discovered more facts about a person previously in my tree, together with two wives and four children. (He was previously present in both Ancestry and RM without this family members.) After adding them all in Ancestry and running treeshare, only three of the new/amended people appeared as changed and there were clearly some problems.

After adding those three people via treeshare, I navigated to their father (not marked as changed) and saw this

Broadbent, the father, in the screenshot above, was not only not marked as changed, but the changes that I had made to his profile in Ancestry were not reflected in treeshare.

The three new people added via treeshare - one of John Broadbent’s wives and two of his children - had been added to RM from Ancestry and appeared properly in RM as related to him, but according to the treeshare view, were not his wives/children in Ancestry. (In Ancestry itself they were.)

Although the two children did not appear in the above screen as Broadbent’s children, he did appear as their father when I navigated to them in treeshare

Broadbent’s first wife, the mother of the four children, did not appear in either of the views above, and was not shown as ‘changed’ but she was in the treeshare file

I added her to RM and ran treeshare again, still not picking up the changes to the father, or the two extra children.

I then added Ancestry notes to the father and two extra children to force changes to them, and they did then appear. The changes I had previously made to Broadbent the father then appeared too.

But this time, not only did the three people to whom I had added notes appear as changed, so too did many other people whom I had not changed in the interim and who had not previously appeared as such.

After using notes to force the changes through, everything appears to be OK, but it is quite possible that changes I have made to other people in Ancestry have not properly flowed through - I don’t keep a note of everything I have done and rely on treeshare to pick things up for me.

So it seems clear that there is something unreliable in the way that treeshare is working with the new API. It is impossible for me to know for sure whether the problem is with Ancestry or with how RM is interpreting the data presented by the new API. However, my guess is that the problem is with Ancestry; when treeshare runs an update, I suspect that RM loads all the data that Ancestry sends it and that Ancestry had not sent all the data concerned.

I’m glad someone else is having issues with tree share not working correctly, I have a previous post about it, I noticed that if my entry had an image then treeshare failed, remove the image and most of the time treeshare would work.
I reported it to RootsMgic but heard nothing more

I’ve seen somethings that mystify me, and are hard to report on. I’ve experienced the changed list data changing everytime TreeShare was open. Right now I can’t see the Ancestry media on the Person row when I use compare. It is on Ancestry and in RM. It showed in 11.2.0 when it was first released. It makes me think Ancestry is still changing things in the background. None of this is harming the databases or trees, it’s just making it hard to know what’s really there. Does not hurt to open a support ticket so we make sure we are seeing it too.

On the issue with family members not being linked, it would be better to not work from the changed list when adding. Switch to show everyone first. That will rule out working with duplicates.

Thanks for your comments. Perhaps stupidly, after taking my screen shots, I forced ancestry changes in the people causing problems and ran treesearch again. And after that, I think that everything was coherent. I’m not sure that your colleagues would have anything to see if I opened a support ticket now.

I watched closely when making a few changes yesterday and didn’t see anything amiss, but I will report back here and open a support ticket if I see a recurrence of the issue.

1 Like

I have been using treeshare every day, so if the problem I experienced recently still exists, it is certainly intermittent.

I have one small idea about what might the cause might have been. (I want to emphasise the might, because it is just an idea and not something I feel at all sure of.)

In the past, I have experienced various connectivity problems with Ancestry when using Treeshare and the connection has often frozen, requiring me to close the screen and re-run it.

If the communications between Ancestry and RM did not complete successfully, but rather than freezing the system had brought up the next screen, then you might have seen problems like those I experienced. It is fairly easy to imagine how a problem like this might arise with a new API.

This may or may not be the cause of your problem, but the new API is creating duplicate repositories for each download from Ancestry. Eventually, that builds up enough duplicates in the repository list that it causes Treeshare to freeze, and I have to end it using Task Manager (which I definitely don’t want to make a habit of). I only realized that this was the issue after submitting a support ticket.

To figure out if this is what is causing your problem, go into the Addresses section from the left navigation bar, click on Repositories and see how many versions of Ancestry.com you have. Run the Merge Duplicate Repositories command so you only have one entry for Ancestry, then try using Treeshare again.

I’m now successfully transmitting data back and forth again, although I do have to repeat this process periodically. That said, I know that development is aware of the issue so hopefully a fix will be coming in one of their upcoming releases.

1 Like

Hi,

Thanks for your suggestion. Looking at the Addresses page as you suggest, I see one main entry for Ancestry.com used 9265 times and many, many other entries for it underneath that. I tried estimating how many by moving down 100 lines and seeing how far the slider on the right moved. There was no discernable movement. From this I guess that I have at least some tens of thousands of entries in the table. (U could count them by peaking inside the database.)

I had previously noticed something similar in the sources table; on the initial download from Ancestry, RM seems to create one entry for each source used, but it then appears to add another entry each time a new citation for the source is in another treeshare session. Therefore I have an initial entry for England and Wales Civil Registration Birth Index 1837-1915 used 7915 times, followed by some 1500 duplicate entries. The same pattern appears for each of the entries in the table which is therefore rather large.

These things might be a problem to some RM users, but I have never felt the need to see everywhere that a single source is cited or repository used, so they wouldn’t bother me unless they do indeed have some some important performance hit.

The ‘sources’ issue certainly applied since Treeshare was created, and was not introduced with the new API. From the numbers cited above, I guess that the same applies to the ‘repositories’ issue. I am not going to merge these tens of thousands of entries manually, but would be interested to hear if you have any response to your support ticket.

The suggestion from support was to merge the repositories so that you only have a single entry for Ancestry. That solved my problem, but the more you download, the more it recurs so you have to do it periodically when you are downloading sources from Ancestry.

You don’t need to merge the sources themselves. As you say the duplication of sources and citations is inherent in how the API works (and worked the same way previously). I am a “lumper,” so I do merge the sources, since I prefer to see a single listing for a source with a citation for each time that citation is used, but that’s a matter of personal preference.

Hope that helps - thanks for taking time to reply.

I had not realised that I could merge them all in one operation. Thanks for pointing me to that. It merged just under 10,000 copies of the Ancestry address repository. (I do not have a single address in the database.)

I also used the equivalent tool to merge all duplicate sources; it merged just under 30,000 duplicates there.

However, I think I have worked out roughly what treeshare does, and I would be very surprised to find that either of these tables has any impact on treeshare performance; I think that these tables are easily read when RM summarises changes since the last update and only written to when you click on the ‘accept changes’ button, usually for a single person or sometimes for a group including children, parents, souses etc. I have never had a problem with comms at this stage; I think that the problems occur when Ancestry is sending its changes to RM, and I am pretty sure that this process does not touch the tables concerned.

I would have agreed with you based on my own knowledge of how APIs typically work, but this is what support told me to do and it worked. I had tried a bunch of stuff on my own before reaching out to them, and frankly this is the last thing I would have thought of if they had not suggested it.

Hope it helps with your problem.