Name Collision Bug?

Advanced Renamer forum
#1 : 29/02-16 00:00
Tuxster
Tuxster
Posts: 3
This used to work in version 3.69 and now does not in 3.71:

I have my photos renamed as YYMMDD_HHMMSS and have the name collision rule set to "Append incrementing number" with a "_" separator, in case there are two photos with the same modified time stamp.

In the past, if it came to two same time stamps, it would name them as:

YYMMDD_HHMMSS_001
YYMMDD_HHMMSS_002

Now it gives a "Error 102 - Possibility of multiple files with the same file name" error and forces me to either stop the batch, or to skip renaming one of the two files.

Is this a bug?


29/02-16 00:00 - edited 29/02-16 00:05
#2 : 29/02-16 00:11
Tuxster
Tuxster
Posts: 3
Reply to #1:

Update on the previous one. In a directory of files, the first set of name conflicts are renamed correctly, if there is another set of name conflicts (or more than two) than those are the ones that fail to be named correctly. Definitely a bug.


29/02-16 00:11
#3 : 03/03-16 05:44
Lobster Boy
Lobster Boy
Posts: 3
Reply to #2:

Yes! I am seeing this exact issue as well. The first name collision is handled with incrementing numbers just fine.

Every other time it has to increment, however, it marks the first file (the 001 in my case) as a potential error. Specifically: Possibility of multiple files with the same name. It doesn't seem to matter how I construct my renaming rule, as I've tried using date modified tags and substring tags.

I'm on Windows 7, if that helps. Unfortunately this bug renders the software virtually useless except in the event that you never have things with similar names.


03/03-16 05:44
#4 : 03/03-16 14:05
Lobster Boy
Lobster Boy
Posts: 3
Reply to #3:

Sorry, I meant to say that I'm on Windows 10.


03/03-16 14:05
#5 : 05/03-16 02:36
Derek
Derek
Posts: 1
Same issue here.

This happens for me when I have "burst shots" in the same directory with other files.

The burst shots start with IMG_001, IMG_002, etc but have the same DateTimeOriginal since they are taken so fast by the camera/phone.

I pefer to rename all my photos to the following format:
YYYY-MM-DD HHMMSS

This way they are in chronological order in my master directory. No matter what photos I add to the master directory, they will fall in chronological order since the 18 character file name will order them chronologically based on the new file name based off the DateTimeOriginal Exif information.

Since the included colllision rule will add the _001, _002 until the collision is over, the file names will never meet the 18 digit file name I prefer, there is a workaround that is not as "clean" but will work until the "bug" is fixed.

Add the Dir of photos you want to rename.
Deselect all the files that have collisions.
Process all the files that don't have collisions.
Reselect all the remaining files.
Add a new "Add batch method" called "Add"
Ensure this new method is at the end (bottom) of the "Renaming Method List"
Click on the <>
Choose <Inc Nr:1> and add any separator you would like. I use"-" so it would look like "-<Inc Nr:1>"
Choose the correct "At Index". In my example, it would be "18"
Apply to "Name"

The resulting renamed file will now have an additional 4 characters "-001,-002, etc" added to it.

The additional 4 characters will not be relative to the number of collisions, but will be in accordance with the files relative position in the Batch list.

After you process these files, they will be in the correct chronological order in the directory.

As I mentioned, this isn't the cleanest way to do it because it wont rename the files based only the collision then restart at next collision, it will just increment continuously until it reaches the end of the batch list.

Request / Rant

In my wildest dreams, when collisions occur where the last digits are the same, the program would increment the last number by 1 digit.

Example of "New Filename"
2014-05-14 155930
2014-05-14 155930 (collision)
2014-05-14 155930 (collision)

would automatically be renamed to:

2014-05-14 155930
2014-05-14 155931
2014-05-14 155932

If there are enough collisions to make it eventually collide with the a file name that is already named what the next file would be named, it would then increment the new collision by "1" until all collisions in the sequence are resolved, at which point, any new collisions would just start over the renaming process.

Example of "New Filename"

2014-05-14 155930
2014-05-14 155930 (collision)
2014-05-14 155930 (collision)
2014-05-14 155932
2014-05-14 155934
2014-05-14 155934

would be automatically renamed to:

2014-05-14 155930
2014-05-14 155931
2014-05-14 155932
2014-05-14 155933 (was the original 2014-05-14 155932)
2014-05-14 155934
2014-05-14 155935 (was the original 2nd 2014-05-14 155934)

This would allow me to keep the consistent 18 character file name length and soothe my OCD.

kindest regards,
d06h0201


05/03-16 02:36 - edited 05/03-16 02:39
#6 : 10/03-16 04:23
Emmanuel
Emmanuel
Posts: 1
Hello, I have this trouble too: "Append incrementing number" does not work well, though the preview of the new name adds the right numbers #001 and #002 to the new filename (I choosed # as separator).

By the way, I'm trying on more than 3200 files in 27 folders and 6 methods (remove, four replace, swap, with one regular expression). Adding a pattern ("Append pattern", for example "<Inc NrDir:1>") produce the same issue.

I also tried on 8 files in one folder and "Append incrementing number" works very well...

v. 3.71

Last update : I have this message "Access violaion at address 00405c6c in module 'Aren.exe". Read of adress FFFFFFFC." (Windows 7 64 Pro, 6 GB of RAM and a lot of free memory).


10/03-16 04:23 - edited 10/03-16 04:39
#7 : 17/03-16 21:28
Kim Jensen
Kim Jensen
Administrator
Posts: 871
Reply to #1:
This is a bug. For the latest version of Advanced Renamer a new collision rule was added. Unfortunately this changed the logic of the existing rules. The bug doesn't show on the first collision pair, but only on the following collisions. This is probably why I haven't spotted this in my tests.

The bug will be fixed in the next release. I might be able to release within a day or two. If not, a new version will be out around easter.

I am sorry for this inconvenience. It will be fixed as fast as possible.


17/03-16 21:28
#8 : 19/03-16 18:16
Lobster Boy
Lobster Boy
Posts: 3
Reply to #7:
Thank you! I'll be happy to donate some money to the cause if this bug can get ironed out. It's really great software but I can't use it yet because I run into this issue every time.


19/03-16 18:16
#9 : 14/07-16 11:56
Bryonie Hopper
Bryonie Hopper
Posts: 7
Hi.

Maybe I'm missing something, but I have 3.72/windows 10 and this issue appears to still be happening to me.

I have a bunch of photos to rename and when I add the Collision Rule (append incrementing number) it works - except that it doesn't put any of the original name in - it ONLY puts the appended incremental number.

2015_05_28_09-52-15-60_NIKON D3300

and then

___--_00__014

Any suggestions about what I may be doing wrong?

Thanks

Bryonie


14/07-16 11:56