* Ancestry, FTM, FH and workflow

[Nick-V]

Rssults on 20) REPO fields

Import file:

Code: Select all

0 @R1@ REPO
1 NAME Lexicon verfolgter Musiker und Musikerinnen (Hamburg Uni musicians database)
1 EMAIL http://www.lexm.uni-hamburg.de/content/below/index.xml
1 EMAIL second email
1 PHON Phone1 
1 PHON Phone2
1 ADDR Address1
1 ADDR Address2
1 NOTE @N99999@

Displayed:
NAME: Lexicon verfolgter Musiker und Musikerinnen (Hamburg Uni musicians database)
ADDR: Address2
PHON: Phone1Phone2 (there appears to be a CrLf between the two entries)
EMAIL: second email

Export File:

Code: Select all

0 @R1@ REPO
1 NAME Lexicon verfolgter Musiker und Musikerinnen (Hamburg Uni musicians 
2 CONC database)
1 ADDR Address2
1 EMAIL second email
1 PHON Phone1 Phone2

Observations:

1. Inconsistent field lengths (noted previously)
2. Unnecessary CONC in output and I thought it was supposed to split a word
3. Inconsistent approach to multi-record handling (overwrites with 2nd or appends second after CrLf) - dangerous approach
4. Incoming NOTE is discarded
5. It appears we have to squeeze what we can...perhaps Web into email...? At least we know the constraints!

[PeterR]

re 2:
CONC means that the following text should be simply CONCatenated with the text on the previous line; note that there is a space after "musicians". So it looks as if, in this case at least, the export has truncated the line after the last space before (probably) the 80th postion.

[tatewise]

2) Next Plugin version will keep CONC/CONT together without intervening SOUR and children.

16) & 18) Next Plugin version will always put ADDRess value in every Event value.
Prefer to retain Standard Attribute values in situ, unless FTM mishandles them.
FH custom _ATTRibute becomes EVENt with ADDRess value, and _ATTRibute value moved to labelled NOTE.
Prefer to retain CAUS values in CAUS tag, unless FTM mishandles them.

20) For REPO, next Plugin version will append _WEB address to PHON tag.
Looks like will also have to append any multi-instance EMAIL or PHON tags together.
Any NOTE text & children will have to vanish for time being.
BTW: Hope you did actually have a NOTE Record @N99999@ for your test!
Otherwise, not surprised FTM discarded 1 NOTE @N99999@ link to it.
i.e.

Code: Select all

0 @N99999@ NOTE Dummy Note Record

11) _AREA and maybe _ASID will appear in OBJE Record local NOTE.

13) SOUR _ABBR Short Title will always appear in SOURce Record local NOTE.

17) _STAT will always appear in FAMily Record local NOTE.

[Nick-V]

Good news....!

2) Thanks

16/18) Mostly yes but I may not fully understand "FH custom _ATTRibute becomes EVENt with ADDRess value, and _ATTRibute value moved to labelled NOTE". I can't remember now what FTM does exactly but surely if it's an attribute (custom or not) the value should go to value and only the child tags to the note. In this way the primary info (Value) gets seen readily. Again I can't remember what I learnt about DIV, CAUS...I just remember DEAT, CAUSE creates an event. Perhaps I should check again FTM naturally does with event, CAUS, it MAY already move it to a note but better if it is formatted deliberately in your own manner for reconstruction.

20) Yes this one has limitations...yes I had a record too.

I need to check again the others too as I simply can't remember where I've been (thus the documentation). I seem to remember FTM imports _STAT as an event so give me time to run thru your plan. I can't remember if OBJE requires local note or note record etc....

[tatewise]

16/18) The point is FTM knows nothing about custom attributes, as Gedcom only allows custom EVENts. So FTM cannot determine when the value is an ADDRess value and when it is an _ATTRribute value, so they must all be ADDRess values. i.e.
FH EVENt . . . . . . > FTM EVENt + ADDRess value
FH _ATTR + value > FTM EVENt + ADDRess value & _ATTR value in NOTE

CAUSe is a Standard Gedcom tag that FTM clearly recognises (at least in DEATh) and hopefully imports and exports OK.

[Nick-V]

OK, thanks. I will try to remember where I was at but am having to track back so hope I'm not getting confused. Let me share my thinking and see if you agree. FH's concept of attributes is that they have a value whereas an FH event does not. Attributes and Events differ in FH but are all simply Facts in FTM. FTM occasionally does different things when faced with incoming Facts (events/attributes). With DEAT, CAUS someone decided CAUS should be a separate Fact (which is corrected again on export). With DIV, CAUS someone decided CAUS should be the Value and Address should go into the Note. With many other Facts someone decided the Value should go into the Value. Quite possibly address always gets put into a note. BTW, this Value is properly known as Description in FTM terms.

Without trying to work out a dictionary of such FTM decisions I came to the conclusion we need to decide where we want our FH data to go. We need to do this with FTM usability, consistency and reconstruction in mind. We probably need to take control away from FTM and make it put data where we want it. This means we need to avoid it doing things for itself where we've discovered it does so. We need to use out own NOTE syntax for addresses and other data not theirs.

So starting again with the one strange exception...lets just be happy with DEAT, CAUS becoming a separate event and self-correcting on export. If we have an address we can still stick to our rule and use Value because DEAT is an Event in FH.

With DIV, CAUS I dislike FTM's inconsistent handling and indeed reconstruction could be compromised by a future FTM program change.

Unless I'm missing something, FTM does not need to know if it's Description field holds (in FH terms) a Standard or Custom Event Address or a Standard or Custom Attribute Value. We need to know it for reconstruction, and for making our choice clear to FH/FTM users.

This approach relies on 2 choices (event or attrib). The aim is to make the address or value more visible by using the Description field rather than the note.

The alternative is 1 choice...we put all addresses in a note. It would be nice to stop DIV, CAUS becoming a value as in FH terms it is not at attribute!

If you have concerns with this I'm sure they must be valid and I'm simply missing the point...

I don't see why this is necessary: FH _ATTR + value > FTM EVENt + ADDRess value & _ATTR value in NOTE

If you are unhappy with some addresses (events) going into the Value and others (attribs) going into the note I get it and I would put all addresses in the note instead. I certainly would not move an attribute value (important) to the note just so an attribute address (less likely) can go in the Value field.

If I understand the concern we are really deciding if address should always or sometimes go into the Value...?

[Nick-V]

Other things:

An FH or plugin Gedcom contains "1 _STAT Unmarried Couple" and as expected this displays in FTM as a _STAT event (bad cursor issue) with a value of "Unmarried Couple". We FH people therefore regard _STAT as an attribute. However, not surprisingly it gets exported as:

1 EVEN Unmarried Couple
2 TYPE _STAT

I am not comfortable letting FTM take a default action as such action might change in future. If we want the same outcome with _STAT perhaps we should translate to a custom event. Alternatively, perhaps we should use FTM's existing marriage Facts although these might not map 1 to 1 with FH's existing status values. How do you feel the former, translating _STAT to a custom event that we can translate back later....simplest?...or a note? Whatever we decide (I think I prefer custom Fact) we should delete _STAT.

Using SOUR and OBJE notes for the other data is good.

[tatewise]

ADDRess
I cannot find your description now, but I understood that FTM often interpreted the value after an Event tag as an Address, not just a Description.

See Ancestry, FTM, FH and workflow ~ Fact formats (12432) that mentions this feature.

I recall a discussion that said FTM interpreted the only valid Gedcom Event value of Y as the address of the French town of Y.

So I seem to have been working under an illusion. You are now saying FH Plugin can export anything we like in the Fact value so it will import into the FTM Description. Does it follow that whatever is in the FTM Description is exported in the Fact value (with some well known exceptions)?

_STATus
This has also had a confused history.
Yes, I left it as 0 FAM 1 _STAT because the requirement was unclear.
Current plan is to move it to 0 FAM 1 NOTE Marriage Status: as that is an existing option and is consistent with the proposal to move tag values to Notes.

I do not understand what you mean by FTM's marriage facts. The list you provided is all the standard Gedcom FAMily Events, so we cannot borrow them for use by _STAT because FH users may use any or all of them for their Standard Gedcom purpose. They must remain reserved for their standard Gedcom use, which is what my comment in brackets in Step 2 was meant to convey.

[Nick-V]

ADDR: Unless I'm losing it more than I already recognise, FTM does not even have an ADDR field for INDI and FAM. It's Facts simply comprise a Date, Place and Description (with note, sour, obje etc.) this latter being the famous Value. This Description is where an attribute Value displays and where an event Value like an address can display if we wish. FTM facts export the Description next to the event tag (a value) and of course FH rejects such values for events but not attributes. Let me double check...but if so, the question remains, what do we prefer for consistency etc...1) put some (event) addresses in the Value or 2) put all addresses in a note and only use the Value for attribs...

STAT: I now find a new screen in FTM dealing solely with relationships. Here one defines a child as natural or adopted etc.

For spouse relationships there are two fields and I need to see what they export and if we can employ them for our _STAT data:
Relationship: Spouse, Partner, Friend, Single, Other, Private, Unknown
Status: Annulled, Deceased, Divorced, None, Ongoing, Other, Private, Separated, Unknown

I can't find where these are output...not on either spouse or the FAM???

For parents and children the options are:
Relationship: Biological, Adopted, Step, Foster, Related, Guardian, Sealed, Private, Unknown

Code: Select all

0 @F3@ FAM
1 HUSB @I2@
1 WIFE @I3@
1 CHIL @I4@
2 _FREL Natural
2 _MREL Natural

I need to see what tags are created...the jury remains out on STAT!

NICK:
BTW, I now also learn that nicknames can be placed into the name field: John "Jim" /Smith/ OBE
Is this an accepted convention and a better alternative to the use of ALIA...it appears to work OK...

[Nick-V]

Yes FTM appears to import and export as we expected so we have control over its limited fields...we just need to make choices (or leave it as it is with one correction below).

FH Plugin exports:

Code: Select all

0 @I4548@ INDI
1 NAME 0 Fake person for source citations /?/
1 EVEN Contact Value
2 TYPE Contact
2 DATE 1 JAN 1900
2 PLAC Contact Place
2 NOTE Contact Note
3 CONT Place Details:	Contact Place
3 CONT Address Data:	Contact Address
1 EVEN
2 TYPE Internment
2 DATE 1 JAN 1900
2 PLAC Internment Place
2 AGE 12y
2 NOTE Internment Note
3 CONT Place Details:	Internment Place
3 CONT Address Data:	Internment Address
1 EDUC Education Value
2 DATE 1 JAN 1900
2 PLAC Education Place
2 AGE 13y
2 NOTE Education Note
3 CONT Place Details:	Education Place
3 CONT Address Data:	Education Address
1 ADOP Adoption Address
2 DATE 1 JAN 1900
2 PLAC Adoption Place
2 AGE 14y
2 NOTE Adoption Note
3 CONT Place Details:	Adoption Place
3 CONT Address Data:	Adoption Address

FTM displays:
Adoption(event): Date, Place, Address with the note which also contains the place and address
Contact(cust attr): Date, Place, Value with the note which also contains the place and address
Education(attr): Date, Place, Value with the note which also contains the place and address
Internment(cust event): Date, Place, NO ADDRESS with the note which also contains the place and address

It seems the plugin is currently using Value as discussed originally except address is not processed for custom events. We know this works because the custom attribute is seen as a custom event.

FTM exports:

Code: Select all

1 EVEN Contact Value
2 TYPE Contact
2 DATE 01 JAN 1900
2 PLAC Contact Place
2 NOTE @N4843@
1 EVEN
2 TYPE Internment
2 DATE 01 JAN 1900
2 PLAC Internment Place
2 NOTE @N4844@
1 EDUC Education Value
2 DATE 01 JAN 1900
2 PLAC Education Place
2 NOTE @N4845@
1 ADOP Adoption Address
2 DATE 01 JAN 1900
2 PLAC Adoption Place
2 NOTE @N4846@

[tatewise]

OK, perhaps instead Fact Value it would be clearer to use Fact Description.
Then the following Description values can apply if you wish:

• Standard Attribute Facts have Description = Attribute value ~ OK.
• Standard Event Facts can have Description = Address 1st line.
  FH import moves Address to new local Note instance easily handled by import Plugin.
• Custom EVENt Facts can have Description = Attribute value for FH custom _ATTRibs.
  Custom EVENt Facts can have Description = Address 1st line for FH custom EVENts.
  Export Plugin also puts Attribute Value: and Address Data: in a labelled local Note.
  FH import leaves any EVENt without Desription as an EVENt with no value.
  FH import makes any EVENt with a Desription into an _ATTRibute with Value.
  An import Plugin can easily reconcile mistakes by using the labelled Note details.
  i.e.
  EVENt with no value that should be an _ATTRibute with no value,
  because Note has Attribute Value: label but no value present.
  _ATTR with Address that should be an EVENt with no value,
  because Note has no Attribute Value: label and Address matches Address Data:.
• Standard Attribute RESIdence has Description = its own style of data.
  RESI is also an oddity in Gedcom because it is an Attribute with no value allowed.
  FH import probably moves Description to new local Note instance (not checked).
  Export Plugin and import Plugin should be able to handle this special case.

For now I would prefer to export FH _STATus in a FAMily record local Note.
Especially since the FTM Spouse Relationship/Status you found does not export from FTM.

The FTM children Relationships _FREL & _MREL match quite closely with Standard Gedcom children PEDIgree relationships and have no bearing on _STAT.

[Nick-V]

Thanks Mike.

I think we are getting close now, agreeing common terminology, determining how FTM works and deciding how best to approach things takes a little thought. We want simple rules if possible, to minimise exceptions and to make usability as straightforward as possible. I'm still considering a couple of things I'd welcome your thoughts on.

I think we can safely agree to put FH data into a formatted note wherever there is no standard FTM field for it, primarily for reconstruction. However, I am concerned if we ever duplicate any of this information in FTM, the concern being that a user (or Ancestry) might update the wrong one! Perhaps we need to in the case of the indeterminate NAME fields but should avoid duplication with everything else?

If we say Fact data is only stored in once place then:

1) should A) all addresses be in a Note for consistency and ease of reconstruction or B) addresses be in the Fact Description where feasible (all events, simply to provide better visibility, sometimes) OR in a note where not feasible (all attributes). I must say, given the evolution of this discussion I am moving towards approach A - simplicity for the import plugin versus a small visibility benefit.

2) should A) an attribute value be in a Fact Description which is the proper place for it or B) in a note. Again I say A as this is what is expected by Ancestry, FTM and it's users - duplicating the same data in a note seems risky even if easier for the import plugin.

If we allow the same data in more than one place we create an obligation to build logic that compares each, and a approach to decide which gets discarded. Keeping off the detail for a minute...do you share this view or have a way around it?

We can make an exception for RESI, indeed the description gets updated by Ancestry.

_STAT, yes again lets keep to the Note alone. It is a custom field and while FTM offers something similar, its not the same, I couldn't find how it exports, and like FH it conflicts with what events can indicate. I recognise the child tags are different but I wanted to cover everything presented on the relationships screen (which deals with all links between people).

I would also welcome your thoughts on this:
NICKname: I now also learn that nicknames can be placed into the name field: John "Jim" /Smith/ OBE
Is this an accepted GEDCOM convention and a better alternative that the use of ALIA...it appears to work OK...

[tatewise]

1) A) is the only viable option for round-trip success.
Remember, Event Description can only hold 1st line of ADDRess.
The Address Data in Note holds all the ADDR CONC/CONT lines and subsidiary tags ADR1, ADR2, CITY, STAE, etc.
If you don't want duplication, then the Event Description = ADDRess must go.

2) A) is the best option for Standard Gedcom Attributes.

The debate is about FH custom _ATTRibutes that export as standard custom EVENts.
Should the attribute value be put in the custom EVENt Description?
It is complicated by FH custom EVENts that also export as standard custom EVENts.
Should these have the custom EVENt Description set to ADDRess?
In either case the round-trip custom EVENt may import into FH with or without a Description and has to be correctly restored to original FH custom _ATTRibute or FH custom EVENt.
My proposal solves this by putting Attribute Value: labelled entry in Note only for FH custom _ATTRibutes.

I tend to agree that duplicating data poses problems, but I am only proposing to duplicate where important benefits offset the problems.
Duplicating part of ADDRess in Description is useful in FTM, but it is your preference, I can go either way, but the labelled Address Data: is essential.
Duplicating Attribute value only applies to FH custom _ATTR case, is useful in FTM, but not essential. However, the labelled Attribute Value: is essential to sort out EVENts on return to FH.
Duplicating Place Details in PLAC tag and in local Note is similar to Address, but essential to allow PLAC value to be normalised in FTM, and after round-trip the original FH Place Details in Note reconciled with FTM PLAC value.

Of the above, the only value likely to change in FTM is PLAC, and we just have to cope with that.
The as yet conceptual import Plugin would report any discrepancies and we must come up with options to reconcile those discrepancies.

John "Jim" /Smith/ OBE is NOT a Gedcom convention, but may be a better option for NICK than the misuse of ALIAs. Should _USED take the same approach? Presumably the comma problem goes away? The labelled Name Notes allow round-trip reconstruction of original FH data whichever way we go.

[Nick-V]

I am starting to get more tired than I should be due to other matters so I hope I've addressed things sufficiently.

Addresses, OK understood, duplication could go...address in note only. The alternative is to provide an option...if users want better visibility of address they can opt for the duplication but must be aware it is for display only and gets lost on reimport to FH (unless the import plugin provides options). Is the option something reasonable that you would consider?

Regarding the custom attributes debate it's good that data is preserved in a note and now you mention choices on a potential import plugin I have less concerns. I tend towards all standard and custom events moving Addresses to the Description (if the option above is set). I tend towards all custom and standard attributes moving Value to the Description. For the way back the import plugin would decide which is an ATTR or EVEN based on NOTE data and would perhaps ask which data (Description or NOTE) to take in preference or report/highlight differences somehow. Does this sound sensible?

I support entirely all master data being labelled data in a note.

With Places I understand we are saying that the FH place will stay in a note and the duplicated place could be normalised against Ancestry. Thinking about the round trip...can the normalised place then be retained in a FH note or somewhere for return to FTM? If so we get the best of both. If we can choose/reconcile on the way back to FH there is no issue...Lets agree...

Thanks for your thoughts on "Nickname". Yes the comma issue disappears and given the choice of NAME or ALIA for _USED I think we should do the same as NICK. Let's agree that then.

[tatewise]

Address: For the time being lets stick with Address in Description for all Events and worry about export/import options later, but both export and import options you mention are reasonable.

Yes, that custom Event/Attribute export/import strategy is sensible ~ Agreed.

Yes, the normalised PLACe should be able to survive multiple round-trips ~ Agreed.

Yes, put NICK and _USED in quotes in NAME ~ Agreed.

[Nick-V]

Thanks Mike, good news...I'll take a little pause for breath then the opportunity to use FTM a little more and see what other topics we've might need to consider...not much I suspect although as round-tripping becomes more likely I start to think about the data we can't hold in FTM. I don;t yet understand witnesses, submitters and certain other things. And I'm still hoping for a full replacement to try to reduce or avoid merges!

[Nick-V]

Mike, would it be possible to deal with NICK and _USED as an option...either to the NAME in quotes or to ALIA.

The reason I say this is that the NAME might get too long to present well...a choice would be better?

[tatewise]

Yes, that is all OK.

Another thing to double-check is Citations:
Do FH INDI & FAM whole record Citations still need to be moved to a synthesised custom Event for FTM?
Do FTM Citation local Notes still not get imported/exported, so need to be moved to Text From Source?
I assume there is no change to the need to copy Source Media to Citations, which is getting trickier the more I investigate how to do it.

[Nick-V]

As far as I can see, citations can only be based on 2 SOUR (an event) not 1 SOUR (an INDI or FAM). Consequently, I demoted INDI citations to the first NAME but this is not possible with FAM as there are no guaranteed Facts which is why the fake Fact idea came up. If we have to create such a fact for FAM then there is an argument we should do this for INDI which would make identifying 1 SOUR events easier later. So, yes, if you agree, the fake event idea for both INDI and FAM is the way to go...there might by multiple citations at 1 SOUR level I guess.

I need to recheck notes.

Yes citations require OBJE links to the SOUR, OBJEcts and the original SOUR, OBJEcts can be deleted where they are there for citation purposes. However, FTM allows OBJE at both citation and SOUR level, citiation being the primary. Given this and FH's normal approach perhaps we should leave the unnecessary SOUR, OBJE links in place, I see no harm at present.

[Nick-V]

Citation note: I am hoping this export then re-export explains.

This is an FTM Export:

Code: Select all

0 @I2@ INDI
1 NAME Father /Smith/ Suffix
2 NOTE @N7@
2 SOUR @S1@
3 PAGE Citation Detail
3 DATA
4 TEXT Citation Text
3 _FOOT Reference Note Source Author, Source 1 Title (Source Publisher 
4 CONC Location, Source Publisher, 1/1/2900), Repository Name, Repository 
4 CONC Address 1 Repository Address 2 Repository Address 3 Repository Address 
4 CONC 4 Repository Address 5 Repository Address 6, Citation Detail. Citation 
4 CONC Text. Citation Web Address.
3 NOTE
4 CONC Citation Note
4 CONT
3 OBJE @M4@
3 _LINK Citation Web Address
2 SOUR @S2@
3 PAGE Citation Detail
3 DATA
4 TEXT Citation Text
3 _FOOT Reference note Source 2 Title, Citation Detail. Citation Text. 
4 CONC Citation Web.
3 NOTE
4 CONC Citation Note
4 CONT
3 OBJE @M4@
3 _LINK Citation Web
1 SEX M
1 BIRT Birth Description
2 DATE 01 JAN 1900
2 PLAC Birth Village, Town, Country
1 TITL Sir
1 ADDR Address Description
2 DATE 01 JAN 1900
2 PLAC Address Place
1 ADOP Adoption Description
2 DATE 01 JAN 1900
2 PLAC Adoption Place
1 ALIA Also Known As
1 AFN Ancestral File Number
1 EVEN Arrival Description
2 TYPE Arrival
2 DATE 01 JAN 1900
2 PLAC Arrival Place

This is the same file imported then exported again. After import the Citation Note appeared in the Reference Note and had been deleted from the Citation Note field. This necessitates resetting the Reference Note as discussed elsewhere...can't remember, think I said delete a couple of records. (see KB step 2 and its reference to the forum).

Code: Select all

0 @I2@ INDI
1 NAME Father /Smith/ Suffix
2 NOTE @N5@
2 SOUR @S1@
3 PAGE Citation Detail
3 DATA
4 TEXT Citation Text
3 _FOOT Citation Note
3 OBJE @M4@
3 _LINK Citation Web Address
2 SOUR @S2@
3 PAGE Citation Detail
3 DATA
4 TEXT Citation Text
3 _FOOT Citation Note
3 OBJE @M4@
3 _LINK Citation Web
1 SEX M
1 BIRT Birth Description
2 DATE 01 JAN 1900
2 PLAC Birth Village, Town, Country
1 TITL Sir
1 ADDR Address Description
2 DATE 01 JAN 1900
2 PLAC Address Place
1 ADOP Adoption Description
2 DATE 01 JAN 1900
2 PLAC Adoption Place
1 ALIA Also Known As
1 AFN Ancestral File Number
1 EVEN Arrival Description
2 TYPE Arrival
2 DATE 01 JAN 1900
2 PLAC Arrival Place

[tatewise]

I think the Export Gedcom File Version 1.7.8 in the KB Step 2 does almost everything discussed so far.

I only say 'almost' because I have probably forgotten something.
It does all the Citation adjustments too, but may not cope with every scenario yet.
Copying the Source Media links to Citation Media links was easier than I expected, but I have been giving it a lot of deliberation before starting coding.

[Nick-V]

Mike, excellent news...it's a bit late at night for me now but I'll grab it tomorrow and start running thru.

I took the step of moving my own data to Ancestry a little while ago. On one hand, I've made great progress with hints and citations and must say, I just cannot understand how anyone with any volume can properly review and update from the hints without using the Ancestry web facility to update...I simply could not consider copying and pasting and linking images etc...moving FH data to Ancestry is definitely the way to go.

On the other hand, my early move to Ancestry comes at a price...I may have left a little data behind and some may need moving around (like creating the notes with titles for reconstruction!). I don't know the scale of the problem yet. But certainly, I'll be finding out when I try to get it back to FH ! One thing I'll have to try is merging an import in FTM using data from the completed plugin.

I'm glad the citation media thing worked out ! It sounds the plugin has really advanced...although we still need to caution users that there are so many variables there are no guarantees just yet !

[Nick-V]

I'm using KB section 2 to organise my testing and to gradually provide feedback. Some restructuring of this page should make it simpler and potentially allow details and feedback on translation processing for which there are no options.

I have set tab 2 back to the defaults for FTM (which we might discuss further) so that I can learn more and test it all. It's running really slowly...was 3% in 3 minutes...now picked up to a tolerable 47% in 8 minutes and appears to speed up further. I suspect the earlier INDI's have more media so it might be media related. I can rerun with options switched off to try and isolate unless you have other clues...

[tatewise]

I suspect the way Source Media are copied to Citation Media has required all the Media files to be reprocessed, and that is taking the time, just as for the initial run of the Plugin.
Subsequently, if a Media file does not change, then the Plugin avoids reprocessing that file, and this is what you have got used to.
See the Plugin Help & Advice > F.A.Q. page.
Also there are all those extra Citation Media to handle!

On reviewing and testing the way Source Media are copied to Citation Media, I have realised there is an even simpler method, which is also compatible with the earlier method for processing Media files, thus avoiding the reprocessing.

[Nick-V]

OK thanks...I'll pay attention to speed on future runs...