Bug when renaming ten or more files using conflict resolution numbers

[Alan W. Smith]

I found a bug in the file renaming that takes place during ingestion when using the following:

----

Photo Mechanic:  4.6.6

Intel based MacBook Pro (2008)

Mac OS X: 10.6.6

with:

Prefs ~ Files ~ Renaming Resolution set to:
Always append digits (1, 2, 3)

Ingestion renaming template:
{year4}-{month0}-{day0}x{h24}{minute}-

----

This works fine if nine images were shot in the same minute, but the tenth one starts to have issues.

The first nine are renamed to something like:

2011-03-20x1226-1.jpg
thru:
2011-03-20x1226-9.jpg

but at the tenth image the period between the file name and extension disappears. Like:

Code: [Select]

2011-03-20x1226-10jpg
2011-03-20x1226-11jpg
2011-03-20x1226-12jpg

etc...

instead of:

Code: [Select]

2011-03-20x1226-10.jpg
2011-03-20x1226-11.jpg
2011-03-20x1226-12.jpg


I ran an additional test to see what happens if 100+ images are taken within the same minute and use that template. The files make it to "2011-03-20x1226-99jpg" but after that, no more images taken in the same minute are copied. Errors appear like:

Error copying: /Volumes/EOS_DIGITAL/DCIM/100EOS5D/IMG_2885.JPG to: /Users/alans/Photos/PM-Test-5-hundreads/IMG_2885.JPG

so you are aware that images didn't move and can go back and address. (Points to Photo mechanic for not doing anything to endanger files when it runs into the bug.)


----

Note, I tried the same thing with the leading zeros version of name resolution (i.e. "Always append digits (01, 02, 03)" instead of "Always append digits (1, 2, 3)"). With that setting, everything worked fine for "2011-03-20x1226-01.jpg" through "2011-03-20x1226-99.jpg". At 100, the same error of not copying files was thrown.

Personally, I haven't run into an issue with the count over 100, I was just doing that to test and see what would happen. However, I have run into practical problems with the first issue of dropping the dot for ten and higher (e.g. "2011-03-20x1226-10jpg" instead of "2011-03-20x1226-10.jpg")

Thanks,
-Alan


P.S. Attaching a screen shot of a set of test images where the error starts to occur at '-10'.




[attachment deleted by admin]

[Luiz Muzzi]

Hi, Alan
I did not understand why you do not just simply use the sequence variable feature instead of using the Append Digit (or Letter, for that matter). That should be used just in the occasional situations when there are more than one file with the same name...
Regards,

-Luiz Muzzi

[Kirk Baker]

Alan,

I found a bug in the file renaming that takes place during ingestion when using the following:

----

Photo Mechanic:  4.6.6

Intel based MacBook Pro (2008)

Mac OS X: 10.6.6

with:

Prefs ~ Files ~ Renaming Resolution set to:
Always append digits (1, 2, 3)

Ingestion renaming template:
{year4}-{month0}-{day0}x{h24}{minute}-

----

This works fine if nine images were shot in the same minute, but the tenth one starts to have issues.

The first nine are renamed to something like:

2011-03-20x1226-1.jpg
thru:
2011-03-20x1226-9.jpg

but at the tenth image the period between the file name and extension disappears. Like:

Code: [Select]

2011-03-20x1226-10jpg
2011-03-20x1226-11jpg
2011-03-20x1226-12jpg


Thanks for the report.  We'll look into it.

-Kirk

[Alan W. Smith]

Kirk,
appreciate the investigation. If you'd like them, I've got a set of 300+ small jpeg test images I can send your way.
Thanks,
-a


----------

Luiz,

While working to define my overall naming convention, I examined the sequence number, but it didn't work for me. This is probably way more than you were looking for, but here's my thinking behind using the conflict resolution number.

For a little background, let me start off by defining my goals:

1) I want to create a id/filename for each image that can generally be considered unique while still being relative friendly for people/clients.

2) The id/filename should be generated when the images are first ingested and never change from that point forward. (I realize this is not how most folks work. I work with data sets where static, unique IDs are critical. This makes it really tough for me to even think about a workflow where image id/filenames change after they are in they are defined.)

-----

So, with that background, I'll walk through why I decided on using the conflict resolution numbers instead of the sequence variable. Let's take a hypothetical shoot with the following:

- two cameras.

- cards from each camera downloaded at separate times.

- first camera shoots 1,500 images

- second camera shoots 400 images.


Downloading the first card using the sequence number would get us something like the following for the first few and last few image filenames:

Code: [Select]

2011-03-20-photo-1300-1.jpg
2011-03-20-photo-1300-2.jpg
2011-03-20-photo-1301-3.jpg
2011-03-20-photo-1305-4.jpg
...
2011-03-20-photo-1530-1497.jpg
2011-03-20-photo-1532-1498.jpg
2011-03-20-photo-1532-1499.jpg
2011-03-20-photo-1532-1500.jpg

If that was all there was to it, there wouldn't be much of an issue. One minor problem is that there may have been images somewhere in the middle that aren't part of the primary shoot. If I took those out, there would be a big gap in the sequence numbers. No big deal. However, the conflict number doesn't suffer from that as much.

Assuming the exact same raw image set above, but naming the files with the conflict resolution number, we'd get something like:

Code: [Select]

2011-03-20-photo-1300-1.jpg
2011-03-20-photo-1300-2.jpg
2011-03-20-photo-1301-1.jpg
2011-03-20-photo-1305-1.jpg
...
2011-03-20-photo-1530-1.jpg
2011-03-20-photo-1532-1.jpg
2011-03-20-photo-1532-2.jpg
2011-03-20-photo-1532-3.jpg

I find that a much cleaner presentation. If I have to pull out some chuck of images in the middle, it basically doesn't change the surrounding names. Another minor win here is that since the main id part of the string is rarely a direct sequential number, it helps avoid questions like, "What happend to photo 135?, I see 130-134 and 136-150, but not 135. Why am I missing 135?" Granted, this can be avoided by re-sequencing, but my goal is to avoid that.


The real trick comes when pulling images from the second camera. Restarting the sequence number, the last few files would end up with something like:

Code: [Select]

2011-03-20-photo-1530-398.jpg
2011-03-20-photo-1530-399.jpg
2011-03-20-photo-1530-1497.jpg
2011-03-20-photo-1532-300.jpg
2011-03-20-photo-1532-1498.jpg
2011-03-20-photo-1532-1499.jpg
2011-03-20-photo-1532-1500.jpg

Or, if you didn't restart the sequence number, you would end up with:

Code: [Select]

2011-03-20-photo-1530-1898.jpg
2011-03-20-photo-1530-1899.jpg
2011-03-20-photo-1530-1497.jpg
2011-03-20-photo-1532-1900.jpg
2011-03-20-photo-1532-1498.jpg
2011-03-20-photo-1532-1499.jpg
2011-03-20-photo-1532-1500.jpg

Either way, it's confusing. There are effectively two independent counters. The first one, with the hour and minute, always moves up. The second one, generated by the sequence number, moves either up and down depending on which camera it's from and what camera the image before/after it came from.

If we used the conflict resolution number, we would get this instead:

Code: [Select]

2011-03-20-photo-1530-1.jpg
2011-03-20-photo-1530-2.jpg
2011-03-20-photo-1530-3.jpg
2011-03-20-photo-1532-1.jpg
2011-03-20-photo-1532-2.jpg
2011-03-20-photo-1532-3.jpg
2011-03-20-photo-1532-4.jpg

I think that format strikes a nice combination between creating a individual,  archival and relatively future proof id/filename while still being readable/usable by us humans.

Cheers,
-Alan


----------


P.S. Yes. In terms of a fully unique id/filename, there are potential issues with this format. Like:

1) You can't safely ingest two cards on separate machines and then combine the directories manually. Each machine might have a '2011-03-20-photo-1532-1.jpg' file.

2) Even on the same machine, it's possible to end up with duplicate names if you ingest cards to different folders. If Photo Mechanic doesn't know that you already have a '2011-03-20-photo-1532-1.jpg' in a different directory, it won't know to increment the conflict counter.

etc...

There are other naming conventions that would help avoid or even eliminate those issues and virtually guarantee a unique filename. For example, I experimented using the full time stamp, including seconds and sub seconds, along with a unique ID for each camera. The filenames would looks something like:

Code: [Select]

2011-03-20-photo-15300232-1-camera6.jpg
2011-03-20-photo-15302742-1-camera6.jpg
2011-03-20-photo-15305512-1-camera7.jpg
2011-03-20-photo-15320346-1-camera6.jpg
2011-03-20-photo-15320302-1-camera6.jpg
2011-03-20-photo-15323107-1-camera6.jpg
2011-03-20-photo-15323939-1-camera7.jpg

Compared to the previous:

Code: [Select]

2011-03-20-photo-1530-1.jpg
2011-03-20-photo-1530-2.jpg
2011-03-20-photo-1530-3.jpg
2011-03-20-photo-1532-1.jpg
2011-03-20-photo-1532-2.jpg
2011-03-20-photo-1532-3.jpg
2011-03-20-photo-1532-4.jpg


For me, I'm willing to trade off those occasional issues for the overall ease of use in working with relatively unique, but much simpler names.

[Kirk Baker]

Alan,

I found a bug in the file renaming that takes place during ingestion when using the following:

I have fixed the bug.  The fix will appear in the next 4.6.7 beta version.

Thanks,

-Kirk

[Luiz Muzzi]

Alan,
Thanks for your explanation.
I myself prefer to use the renaming feature and I really use it frequently because it is simple and fast. This way I can maintain a sequence even if I have deleted some of the images.
Anyway, as they say, "whatever floats your boat"...
Regards,

-Luiz Muzzi