Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[d_pert]

Hi:

I have a custom field called "Date Acquired (DP)" which I've been using for years in many of my files. It's set to be stored in tags (and it is).

Yesterday on a 'main' PC, using MC, I cleared this field (deleted its contents) in certain files. The tags updated as expected. The files' date modified changed as expected. All was well.

Then I mirrored those changed files to a 'secondary' PC where I also run the same version of MC, with all the same custom fields, settings, etc. This mirroring routine has worked for years, and I've periodically edited custom fields' contents in files before, and the changes have been picked up on the secondary PC's MC, too, upon Import.

However ... this time ... When I ran MC's Import on the secondary PC to update based on the changed tags, MC did not pick up those changes. It did not clear the dates. It kept the old dates that had once been in that custom field.

I discovered that if I changed -- instead of cleared -- the date in the same custom field, in the same files, then mirrored the files again: that kind of change DOES get picked up following Import.

However, clearing (deleting) the field contents does not. The MC database on the secondary PC does not treat the custom field as changed when it's simply been cleared.

It's possible that this has always been the behavior in MC; I don't think I've ever cleared the date from a custom field before.

[RoderickGI]

I believe that is the designed behaviour. MC doesn't overwrite a Library field with an empty value. It retains the value it had.

I'm not even sure MC will write a tag, custom or standard, to a file if it is empty. I think it just deletes the tag, in which case, there is no empty tag in the file to overwrite the existing field value anyway... Yep. If the custom field is empty, it isn't written to the file, and is deleted if it was already there with a previous value.

[d_pert]

Good to know. Thanks sharing the detailed knowledge.

Could it be made optional, perhaps?

[RoderickGI]

Making it optional would require empty tags to be written to files, and for empty tags to update the Library.

The first would slow MC quite a lot, as all tags would have to be written to every file every time it was updated. It would mean a lot of redundant (empty) tags would be written to files. That may well break other applications. I thought about using MPL Playlists to transfer the tag changes to a second Library, but MC only write tags with values to those files as well.

The second could well mean that users accidentally overwrite a lot of tags with empty values, losing a lot of metadata that is only stored in the Library.

What you could do it create a Playlist of the files that you are going to edit that date out of, transfer that Playlist to the other Library, and then do the same edit over there.
Or, enter some weird date into the field in the first Library, such as 01/01/2500, let the second Library pick up that date via Auto Import or a manual run of Auto Import, then with background Auto Import turned off, delete the date in both Libraries separately, using a View based on the weird date to find them. Then turn background Auto Import on again, if you wish. Or use some other custom field or keyword to flag which files should have their date deleted. Something like that.

[d_pert]

A belated thank you...

I just experienced this again, and benefited from your post.

However, now I have a suggestion for MC:

Make "Update Library (from tags)" clear custom fields in database which are found non-present/blank in the file(s). That would seem to suit the usual, manual/fix-related context for that function, in a narrow and measured way, and thereby allow folks to get around needing to do more elaborate workarounds without causing all imports to be elongated. Note: I'm only suggesting this for the one direction: tags to database.

Thank you.