Page 1 of 1
Search and Replace plugin
Posted: 16 Dec 2020 14:02
by gapperly
The Search and Replace plugin freezes and FH must be shut down.
Search and Replace version 3.1, Family Historian 7, Windows 10.
The project contains nearly 7,000 URLs saved as notes to either a source or a citation associated with an event under an individual record or a family record. The Search and Replace plugin takes about 10 seconds to locate and list all of them. I used the Search and Replace plugin to convert all 7,000 to web links. The process takes about 3 minutes, completes normally, and reports the 7,000 results. The web links function correctly and FH reports no errors.
But the Search and replace plugin will no longer work. The plugin freezes in less than 10 seconds when attempting any search.
I tried doing the replacements in smaller batches and everything worked until I had completed about 1,000 replacements, then it froze again.
What could cause this problem?
Re: Search and Replace plugin
Posted: 16 Dec 2020 14:12
by tatewise
Could you please provide some more explicit details?
Does the problem only affect this one Project or all Projects?
Does closing and reopening FH cure the problem?
How are you constraining it to "smaller batches"?
What are the search and replacement text and other settings ~ a screenshot of both tabs might be useful?
Re: Search and Replace plugin
Posted: 16 Dec 2020 15:00
by gapperly
The problem does not occur in a smaller project. Closing and reopening FH does not resolve the problem, nor does reloading the plugin. I selected smaller batches by making the search more specific, identifying individual Ancestry collections for instance. I'm not sure how to include a screenshot, I'll try this.

- options.PNG (90.14 KiB) Viewed 2034 times

- extras.PNG (149.44 KiB) Viewed 2034 times
Re: Search and Replace plugin
Posted: 16 Dec 2020 15:41
by tatewise
You have some interesting selections on the Extra Filters tab.
Multimedia Exclude flags can never contain URL.
Source Template record fields seem unlikely to contain URL.
Templated Source metafields similarly seem unlikely except perhaps in the URL metafields.
I have read your original posting again and I am not sure I understand how your screenshot fits.
You say that the plugin has successfully converted 7,000 URL perfectly in about 3 minutes.
Then you say the plugin freezes attempting any search.
Then it works in batches up to 1,000 replacements.
Are your screenshots of the original successful 7,000 conversions or of a search that freezes?
Have you tried it with Confirm the action for every item found ticked?
What is currently in the Notes you are searching and what are the plugin Search and Replace text boxes?
How long does the plugin stay frozen?
Sometimes with a large Result Set it does take a while to exit.
What do you do to proceed?
Re: Search and Replace plugin
Posted: 16 Dec 2020 17:26
by gapperly
I didn't notice the three extra filters, I deselcted them and the plugin still freezes. The search scope is all possible records and the only item selected on either tab is note and description fields. The text for the search and replace are exactly as shown in the attachment and remain the same throughout the process.
The notes I am working with contain nothing but a single URL.
This is the basic process. 1) Run the plugin as search only to identify the target URLs. 2) Run the plugin as search and replace to convert the URLs to web links. This action always succeeds, I can return to FH and confirm that the new web links function properly. 3) Run the plugin as search only again to identify any URLs that were missed. It is at this point that the plugin freezes, apparently at the same place each time because the progress dialogue always stops at 35%. I have waited as long as 30 minutes but the plugin never resumes. 4) Force the plugin and FH to shut down. 5) Restart FH and restore the gedcom from a previous snapshot. 6) Try something else.
After step 4) any attempt to run search and replace to search for any text in an individual record causes the plugin to freeze.
I generally start a search and replace with confirm selected to visually verify the expected result. Obviously I am not going to confirm 7,000 items.
Here is a random sample from the gedcom before and after the replacement.
Before
2 _SEQ 1
1 NOTE
https://central.bac-lac.gc.ca/.item/?op ... id=211346a
1 CHAN
After
2 _SEQ 1
1 NOTE <web="
https://central.bac-lac.gc.ca/.item/?op ... 6a","Image">
2 _FMT 1
1 CHAN
Re: Search and Replace plugin
Posted: 16 Dec 2020 18:35
by tatewise
Thank you for that much clearer description.
With a bit of lateral thinking, I think I have discovered the problem.
You claim that "The notes I am working with contain nothing but a single URL."
However, if a Note contains multiple URL then the symptoms you experience can occur.
e.g.
http:\\www.xyz.co.uk
http:\\www.jkl.co.uk
http:\\www.abc.co.uk
That results in:
<web="http:\\www.xyz.co.uk
http:\\www.jkl.co.uk
http:\\www.abc.co.uk","Media">
FH really does not like that and eventually freezes.
So change your Search to the following so that new line will terminate the URL.
^(http[^¶
]+)$
Then use the following to convert the multiple URL.
Search:
¶
(http[^¶
]+)
Replace:
¶
<web="%1","Image">
Re: Search and Replace plugin
Posted: 16 Dec 2020 20:11
by gapperly
Thank you very much Mike, your solution worked.
I ran your revised search criteria which returned all but 3 of the original results and I converted those without incident. I then ran the original search to identify the 3 culprits. A closer examination of the actual notes revealed a linefeed at the end of the URL. Problem solved.
The invalid web links look like this:
<web="
https://www.ancestry.ca/imageviewer/col ... 1572-00018
","Image">
Re: Search and Replace plugin
Posted: 16 Dec 2020 20:48
by tatewise
Ah, yes, a rogue linefeed would do it too.
I am thinking about whether to report the problem of the freeze to Calico Pie.
It is only going to happen when 'rich text' formats like that get upset.
I have not yet worked out whether there are other scenarios than the Search and Replace plugin where it might happen.
I guess if somebody tried to manually edit the GEDCOM file and got it wrong then it might happen.