PM5 loses frame number when renaming on ingest

[michaelbothager]

Hi

When ingesting CR2 images from a Canon 5D mk III, and renaming from the ingest dialog, the frame number is blank afterwards. If no rename is performed during ingest, the frame number is retained. See attached images.

Also, PM 4.6.8 retains the frame number.

Setup is Photo Mechanic Version 5.0, build 13217 (68ec133) on Mac OS X 10.7.4

Rgds
Michael

[attachment deleted by admin]

[michaelbothager]

Does nobody else have this issue?

Additional info - if the ingest is done without rename, and a rename is performed from PM5 (CMD+M), the frame number is kept intact. But this takes extra time, and involves another step in the workflow, and if the same job requires multiple ingests at different hours, it really becomes a pain in the behind.

I've read in the forums that a similar issue once existed in PM4.x. (in late 2011) Back then, it was suggested that using the last four numbers  of the filename - but if/when the file name no longer contains the frame number, this is not possible. But this bug apparently got fixed at some point, since it works perfectly in 4.6.8 & 4.6.9 - only to reappear in PM5.

Kirk, Any ideas/plans about how to a fix this in PM5?

Anybody???


Rgds
Michael

[Kirk Baker]

Michael,

Dennis is working on a fix.

-Kirk

[michaelbothager]

Kirk,

Thank you.

Rgds
Michael

[Junction10]

Does nobody else have this issue?

Yes... I didn't see this thread when I posted the same problem a couple of days ago..  (there's also a problem where two different frames show identical {Actuations} which should be impossible....

Glad to hear a fix is in the works...

[Kirk Baker]

Does nobody else have this issue?

Yes... I didn't see this thread when I posted the same problem a couple of days ago..  (there's also a problem where two different frames show identical {Actuations} which should be impossible....

Glad to hear a fix is in the works...

We'd have to see these two images from you.  We have not encountered this problem ourselves.

-Kirk

[Junction10]

Can I email you a dropbox link Kirk?  It's the RAW files that are affected and I'd rather not post them publicly.

[dennis]

Additional info - if the ingest is done without rename, and a rename is performed from PM5 (CMD+M), the frame number is kept intact. But this takes extra time, and involves another step in the workflow, and if the same job requires multiple ingests at different hours, it really becomes a pain in the behind.

I've read in the forums that a similar issue once existed in PM4.x. (in late 2011) Back then, it was suggested that using the last four numbers  of the filename - but if/when the file name no longer contains the frame number, this is not possible. But this bug apparently got fixed at some point, since it works perfectly in 4.6.8 & 4.6.9 - only to reappear in PM5.

Michael,

I have some questions so I can reproduce this.

1) What are you using for rename during the ingest?  Are you using the sequence variable?  Or are you doing a rename like "blahblah{fnum}"?

2) What are your IPTC/XMP preferences (for the format you are using)?  Are you reading IPTC before XMP?

I assume number 2 may be the problem (you might try reading XMP before IPTC), but question number 1 is important.

--dennis

[michaelbothager]

Hi Dennis

I am using the exact same settings with PM 4 and PM 5, where PM 4 works as expected.

The answers to you questions:

1) I am using {frame4} like this: {jobname}-={serialnum}=-{frame4} - so no sequence variable. Also, the framenumber part of the filename is retained when renaming during ingest. It is only if a rename with the string is performed after the ingest, that the empty frame# is a problem.

2) IPTC/XMP setings have "Read embedded IPTC before XMP". I have also tested right now with XMP before IPTC, and the farm# is still missing, see attached screen grab.

Currently, I am still using PM 4 in my daily work where everything is fine, but I would like to take advantage of the new features and speed of PM 5.

Let me know if I can provide any other information.


Regards
Michael

[attachment deleted by admin]