Filename renaming error -- only occurs in secondary destination

[crunge]

I'm running Photo Mechanic 4.6.2.1 on Mac OS X 10.6.2 (Intel).

When ingesting new photos, I am running into what I think is a bug that only occurs to photos copied into the secondary destination.

Ingest is setup as follows:
1. Copy Photos into folder with name
2. Folder Name: {year4}/{year4}_{iseq}
3. Use folder sequence: 001
4. Rename Ingested Photos As: CJR_{year4}_{iseq}_{frame4}

Photos ingested into the Primary Destination are ingested and renamed properly, e.g., CJR_2009_001_0670.NEF

However, the first photo of each ingest session is improperly named in the secondary destination, e.g., what should be CJR_2009_001_0670.NEF is instead named CJR_2009_0_0670.NEF. The remaining photos in the secondary destination are all renamed properly; it is only the first photo that experiences this problem.

Any thoughts?

[Kirk Baker]

I'm running Photo Mechanic 4.6.2.1 on Mac OS X 10.6.2 (Intel).

When ingesting new photos, I am running into what I think is a bug that only occurs to photos copied into the secondary destination.

Ingest is setup as follows:
1. Copy Photos into folder with name
2. Folder Name: {year4}/{year4}_{iseq}
3. Use folder sequence: 001
4. Rename Ingested Photos As: CJR_{year4}_{iseq}_{frame4}

Photos ingested into the Primary Destination are ingested and renamed properly, e.g., CJR_2009_001_0670.NEF

However, the first photo of each ingest session is improperly named in the secondary destination, e.g., what should be CJR_2009_001_0670.NEF is instead named CJR_2009_0_0670.NEF. The remaining photos in the secondary destination are all renamed properly; it is only the first photo that experiences this problem.

Sounds like a bug.  We'll look into it.

-Kirk

[Kirk Baker]

However, the first photo of each ingest session is improperly named in the secondary destination, e.g., what should be CJR_2009_001_0670.NEF is instead named CJR_2009_0_0670.NEF. The remaining photos in the secondary destination are all renamed properly; it is only the first photo that experiences this problem.

We were able to reproduce this bug and have fixed it.  The fix will appear in the next 4.6.2.2 beta (and final release)

-Kirk