No matches even though I have matching persons in the tree
Posted 17 April 2013 - 07:14 AM
When I export a GEDCOM from Gramps, and import it into RM, I get no matches with the tree, even though I have most of my ancestors there. When I download the tree from FS, I see that all ancestors are there, with the exact same names as I have them in RM, and RM can merge most of those automatically.
With the previous version, I got loads of matches against nFS, and I know that the tree has less persons in it, but I would expect the matching process to work against the persons that I uploaded myself earlier. Is there a problem with search?
Posted 17 April 2013 - 10:46 AM
If your download from FT into your RM database then all the IDs are being included automatically. That is why they are showing as matched.
Posted 19 April 2013 - 07:48 AM
But the real problem I see now is, that when I have a person without such an ID (which means unmatched to RM, I know), I expect search to find that person (or close matches) in the tree, just like it did with nFS in the previous version.
But todays reality is that search never returns anything, even if a person in the tree has the exact same data as I have in RM, i.e. even if I uploaded that person earlier myself.
Posted 19 April 2013 - 09:02 AM
NFS had a lot more data on individuals that could be compared for potential matches. When information was moved to the FT only the summary view items in NFS came over. That limits the amount of information that could be compared as a match. When you are on the Find Matches tab in the FamilySearch Person Tools click on "Search for more matches" to broaden your search criteria.
Posted 20 April 2013 - 06:22 AM
I'm checking search for my grandfather right now, and even when I use "search for more matches" clearing everything except his first and last name, I get no results. And even a search with surname only provides NO results in RM.
Posted 20 April 2013 - 06:38 AM
My log-on credentials are OK, since I can add new persons to the tree from RM.
Is there a way to get some sort of communications log?
Posted 20 April 2013 - 02:13 PM
The only search that DOES work from RM is search on ID, which is useless, because when I have the ID, I don't need to search ...
Posted 22 April 2013 - 10:49 AM
Open a support ticket and include a File>Backup (.rmgb) of your database, and the name of the individual to test.
Posted 22 April 2013 - 11:52 AM
The problem I have with RM 184.108.40.206 is that no matches are found, ever, even when they are there, for instance because they were already entered by my cousin who goes with username DoddemaGen here. And that's a problem that affects every new person that I have in RM, no matter whether he/she comes from a gedcom file created by Gramps, or by a cousin who doesn't use the FT, or whether I entered this person myself, after researching a local archive/site.
In all these cases, I expect that RM finds existing persons in the tree if they are there, so that I won't duplicates. That doesn't work, and it has never worked for me in the tree version of RM. It did work for the nFS version.
To illustrate this:
When I log-on to the tree with chrome, and search for Hindrik Doddema, I see 16 results, most of which were entered by DoddemaGen.
When I start the same search in RM, I see nothing.
Posted 22 April 2013 - 12:44 PM
Posted 22 April 2013 - 03:08 PM
Search worked for me in all nFS versions, i.e. in 6.0, but it has never worked in the FT version, beta and 220.127.116.11.
I'm asking, because to me it looks like the nFS versions are OK, and the FT version is faulty, search wise, but if anyone can prove that search actually works in 6.1, I may have to look for some sort of network error. That's a bit harder to do, but I can and will do it when nothing else helps.
Posted 22 April 2013 - 05:29 PM
Posted 23 April 2013 - 07:50 AM
Today I tried to eavesdrop on the network traffic, using Wireshark, but that doesn't help, because the traffic is encrypted. I can see that RM contacts FS, but that's all.
Your experiment proves that RM 6103 can do the search, but somehow it still doesn't return anything here, which means that I need to analyze what's different between your and my setup, which can be:
1. Different Windows configs, mine is Dutch, XP and 8, both fail,
2. Different networks. I'm in The Netherlands, but I can access FS and RM sites, and search on-line,
3. Different FS accounts. I'll try to sign up for another one, using another username and email address.
Posted 23 April 2013 - 08:12 AM
A new FS account doesn't help. I need to get an insight in the network traffic between RM and FS. Maybe RM is not authorized for FT access outside the U.S. or so. No idea.
Posted 23 April 2013 - 08:19 AM
Edited by TomH, 23 April 2013 - 08:26 AM.
Posted 23 April 2013 - 08:36 AM
Open a support ticket and include a File>Backup (.rmgb) of your database.
Posted 23 April 2013 - 09:40 AM
@TomH, yes, I perform every step you describe, i.e. match, then search for more, and I see that RM goes on-line to search and waits a few seconds, but no matter what, the result is always zero. I'm on Dutch Windows 8 Home 64-bit, no word about premium. Same problem on Dutch Windows XP in virtual box.
I created a support ticket on the FS site too, hoping that maybe they can check some logs, or tell me whether RM is authorized to search the tree from outside the U.S.
Posted 24 April 2013 - 10:11 AM
This US Windows XP Pro is not properly licensed to me, so I'm still thinking about how to tweak my licensed Windows 8 so that RM 6103 runs in a US like environment. Also, I still don't understand why Windows language makes a difference for RM 6103, where it had no ill effect on RM 6005.
The results I get are perfectly repeatable. All Windows copies that I use run on the same hardware, same network, same ISP, etc.
Posted 24 April 2013 - 11:34 AM
I tested your database and I had no problems getting search results with RM FT sync. That's because I have a US version of Windows. I will pass it along to development to see if there is anything we can do on our end, or if it's a FT API issue that needs to be addressed by FamilySearch.
Posted 25 April 2013 - 04:18 AM