they were not directly pasted from – I copied them from a chat I asked someone if they evey saw that before. I tried repasting hopefully they are slightly better but I do not have the originals
I’ve seen that happen. You were on Herbert and then switched to Mattie right below him. For some reason FamilySearch just didn’t keep up and load Mattie. If you click on her a second time or use the refresh button it should load her.
I will try to capture it on video next time it occurs – yes FSC seem to be outta whack when it happens and it tends to happen when scrolling down the list of people.
The correct fsID for the My RootsMagic Person was LZYC-725.
I’m not inferring that your table got corrupted. That your example showed a mismatch with the person adjacent suggests that it is a timing glitch from stepping through the list of Names. The MyRootsMagic panel displays the person your stepping settled on while the My FamilySearch Person displays the result of the query of the FS server launched by a previous step. It’s as though the last selection failed to launch its query.
By jumping through the list I’ve seen at least temporary mismatches because the right column is slower to update than the left. And here is one that stayed mismatched - note that fsIDs are indeed different, unlike my forced case. And note that the names are not adjacent in the list - that’s because I jumped all over the list.
in the cases I have seen or concerned with – nothing had changed (yet) on either FS side or RM side. I was going through the list in alphabetically (NeverMarried) that began at around 2000K people last night I was working through the L’s when it occurred.
The result you showed above is what is NOT EXPECTED L8WW-DYP vs KN7M–…) that is what I would consider a BUG and could be results of previous API call but bottom line the RIGHT side has nothing to do with LEFT.
Harold S Annis should be displayed on both. What could be concerning about this other than user confusion if someone may changes to the FAM SEARCH side that could cause headaches for the global tree if something was passed to wrong person on FS side.
My first example was done on a very old, slow computer from the Win8 era. I find that the misalignment is also easily triggered by fast stepping on my much faster Win11 computer. Moreover, one can copy data in both directions, from RM to FS and from FS to RM which is very concerning.
The following example is adjacent in the list as I was stepping down through it rather than jumping around.
The cause of this misalignment could be on either side. Either:
RM fails to send the last query to FS, OR…
FS fails to respond to the last query it has received
and RM only shows the last result it has received.
Maybe the software needs to have added to it a check that the bundle of data received for a ‘matched’ person has the same fsID as the selected RM person before displaying it.
Not sure if is a API issue or RM is asking for wrong info and is step behind.
that is very concerning.
Been trying to capture on video for 15+ mins have not been able to .
I have newer computer (1 years old very fast SSD/PCIe () and 32gb ram)
Main disk is ADATA Legend 710 (PCIe Gen3 x4 interface and NVMe 1.4 protocol. It offers sequential read and write speeds up to 2,400 MB/s and 1,800 MB/s)
I can pretty reliably trigger this misalignment between FamilySearch and RootsMagic in the FS Person Tools window and have recorded a video demonstrating it:
Sorry, it’s a bit long at 10 minutes but that’s because I tripped upon a previously unnoticed problem at around the 6:15 mark when it appeared that the two different people had matching fsIDs.
That’s what I have seen, and it has been reported. The best thing to do with you jump through the index it to take a quick look at the name and FSID and make sure you have the right person before moving data back and forth. Things are usually off enough you can tell somethings not right.
Thank Tom for replicating and catch the problems in the action – this is what I say but was not able to catch on video when I tried – I think I needed to jump more than one or two positions for it to “Trip”.
