Bridge, newest version 220.127.116.115, Windows 10 Pro.
Heads up: "Batch rename" produces unreliable results.
A simple renumbering of frames
from name.0000.png name.0003 .0006 .0009 etc.
to name.0001.png name.0002 .0003 etc.
Batch rename decides to shuffle the renumbered frames and reordering the sequence.
Weirdly batch rename with the exact same settings, worked on my colleagues pc, same Bridge version.
Cheers, Mikkel 😉
adobe suggestions have greater effect if made elsewhere.
for applicable apps, you can make (some) suggestions to adobe here, https://helpx.adobe.com/ie/x-productkb/global/how-to-user-voice.html
for others, use https://www.adobe.com/products/wishform.html
<moved from cc desktop bugs>
disagree all you want, but if people want to make suggestions/reports to adobe, it's best done elsewhere.
@Mikkel29816245c33v the curious thing is that the problem does not happen on your colleague's PC. I'm not able to reproduce the problem, but I wonder if has something to do with the dot in your filename.
Can you send a screenshot of your batch rename settings?
Yeah sure, thanks 🙂 - as you can see it's pretty straight forward. I have rendered frames on threes but the pipeline requires frames numbered 1, 2, 3, 4... All Bridge needs to do is copy the original alphabetical/numerical order and renumber from 1....and yes, I totally agree to the dodginess of my colleagues pc doing it right 😉
The AdobeBridgeBatchRenameTemp bug comes to my mind, too.
Bridge13 on Windows 10 still has a nasty bug from previous versions, that occurs when renaming a set of items a second time. We often need to adjust the display sequence of images for tools which don't support manual sorting. Hence, if we're not happy with a stack of related images we drag and drop adjust their order and run batch rename a second time. File-Names stay the same, just their sequence numbers do change (see sample below).
My hunch is that the error gets triggered by items included in the batch-rename-stack, which retain their previous name. Bridge seems to hate assigning the same name to files a second time. This is a long-standing, repeatable malfunction.
Shuffled sequence, renamed again:
FYI @Mohit Goyal
This definelty could be related to the AdobeBridgeBatchRenameTemp issue.
Using @Mikkel29816245c33v rename settings I experienced a slightly different problem. The order was retained, but the second file image became a duplicate of the first file. So there is definitely a bug there.
I then ran a test using an underscore instead of a dot ("example_v02_") and there were no problems.
@Mikkel29816245c33v could try testing the rename "example_v02_" to see if the dot is causing the problem? It might not be possible to change your filename format, but it would running that test would help to narrow down the cause.
Thank you so much for all your suggestions and insights 🙂 I rendered a simple test animation for the example screenshot above. Same naming convention no errors. I then ran the batch rename on a new version of the animation I´m working and this reproduced the error. This should just work right? 😄
For those interested I have solved the issue in Nuke where I'm working on the sequence. Renumbering in Nuke has a very easy workaround that I gathered from: Changing the Numbering of Rendered Frames (foundry.com)
The article does not mention this exact example, but you can obviously use expressions in the Read node. Just import the sequence (3,6,9,,,) as you would, as a sequence, then add "frame*3" after Frame/expression.
I'm glad you found a working solution in Nuke but yes, the Bridge batch rename should just work.