Closed iburunat closed 8 months ago
Thanks for the detailed report. What do you mean by the counter being "random"? The files are handled in the order they are visited, which depends on the filesystem and is not always alphabetically correct.
Exactly. So for instance, my list of photos is this one:
Which after the processing gets converted into this:
However, the rearranged photos deviate from the original sequential (chronological) order. Consequently, when navigating through the converted photos, they exhibit time jumps, creating a rather frustrating browsing experience.
Is there a way to tell Organize to follow a strict handling order?
I see the problem. This should really be handled in alphabetical order. I'm on it.
Thank you! I intended to mean alphabetical order, as the photo file names naturally align with the chronological order.
I decided to use natsort
for this, so the files are sorted just like in the system file explorer. The fix is already on the main branch and will be released soon. Thanks again for the issue!
Just released the fixed version in v3.2.1
Describe the bug I consistently face an issue where file renaming with counter (
on_conflict: rename_new
) results in an order that doesn't align with the original chronological sequence, but a random order, of the files.Environment
organize --version
: organize v3.1.1Your config file The first rule involves resizing an image with the "_r" suffix, transferring metadata from the original file to the newly resized file, synchronizing the timestamp of the resized file with the original file's, moving the original file to the Trash, and ultimately removing the "_r" suffix from the preprocessed file, thereby replacing the original image with the resized version.
The second rule renames the preprocessed photos with year-month-day_counter and sorts them in date folders. Here the counter seems to be random.