Propagation of too many tags

[PandDLong]

I set up a manual version relationship and used the Advanced option to select just one tag to propagate with a defined value from a variable.  The line is:

-XMP-dc:Source={File.Name|substr:0,14}

All of the check boxes in 'What to Propagate', 'Use this Version' and 'Categories to Propagate' were unchecked.

When I wrote back the Master, many things propagated to the 10 version files - including: my requested tag, label, rating, title, and the date created.   (perhaps more, that is what I can easily identify as having changed).  The 10 version files also had a Legacy IPTC Data block generated  (the Master had none and after propagation still doesn't).

I did a couple tests in my Test database to confirm that this problem re-occurs when no other propagation is requested just some Advanced Propagation. 

Happy to provide more information if that is useful.

Michael

[Mario]

(...) option to select just one tag to propagate with a defined value from a variable.  The line is:

-XMP-dc:Source={File.Name|substr:0,14}

All of the check boxes in 'What to Propagate', 'Use this Version' and 'Categories to Propagate' were unchecked.

So what you are basically doing is to not propagate anything but set one tag in the output file via a variable.

That unfortunately breaks the command chain IMatch sets up for ExifTool. Propagation basically tells ExifTool to use data from the master via the -tagsfromfile command, and then specifies the tags (or tag groups) to copy.
When the user has added custom tags to copy (or to exclude) these are appended.

Since you don't propagate any metadata at all, what is sent to ExifTool is basically:

-tagsfromfile <master file)
-XMP-dc:Source={File.Name|substr:0,14}
<version file name>

And that means "copy everything from the source file" and then set the Source tag to this value.

I did not anticipate that a user would ever do this, not propagating any metadata but trying to set just one tag via a variable. I guess that's pretty uncommon. But valid.

You can work around this by propagating one or more XMP tags in addition to your custom tag. Use something like transmission reference or another tag you usually don't fill.

Note that creating an XMP output the way you do creates only a minimal XMP record, missing some important XMP fields. If that is what you intent, OK for me.

I will think about a special treatment for this rather unusual non-propagation case for the next release.

[PandDLong]

Thanks for the quick response Mario.

I was thinking that work-around was a likely solution.

I did notice more tags had been propagated (like 'Preserved File Name'), so I was thinking it was an 'all' situation.  Good to have that confirmed so I can assess what I may need to do to restore anything important. It is also a good reminder to always use my test database first.

As it is an unusual scenario, perhaps no code change is needed just a short note in the Help section to highlight the way it works - and what not to do.

As a side note, in my case, the version record already has a complete XMP record, I am using this propagation to enable a file naming standard where the version uses the same first 15 characters of the master (which in my system is unique). This propagation gives access to this file name "prefix" in the Renamer when it is applied to the version files.

Michael