Page 1 of 1

Endless hourglass when trying to rename JPGs

Posted: 28 May 2025, 10:09
by ahrensjt
Hi all,

I have about 12,000 JPG files from Google Photos, sitting in a folder on a Synology NAS.

The plan is to rename them, them restructure into YYYY/MM-DD folders... then Immich.

My script is not too complex (I think):

Format: Select all

{allOf{ct.format(/yyyy-MM-dd_hh∶mm∶ss/)}{camera.maker.space("_")}{camera.model.space("_")}.join('_')}
The names show up nicely in the right-side list box, but when I press "Rename" I get an endless hourglass.

Other apps have no problem manipulating files on the NAS/folder (e.g., Syncovery, Affinity Photo).

Suggestions appreciated to get this working.
Thanks,
Jeff

Re: Endless hourglass when trying to rename JPGs

Posted: 28 May 2025, 10:53
by ahrensjt
More information, possibly relevant or a related problem:

I was testing {allOf{dt.format(/yyyy-MM-dd_hh∶mm∶ss/)}{camera.maker.space("_")}{camera.model.space("_")}.join('_')}
on DNG files. I changed ct to dt (date taken).

In Windows File Explorer, many files have a Date Taken of 2018-10-28... but FileBot is showing Date Created (oddly with a date of 2020-06-14).
[img][https://drive.google.com/file/d/1ARHHvj ... drive_link]
[img][https://drive.google.com/file/d/1AyUg04 ... drive_link]

Also... isn't the Minute incorrect? File Explorer is showing 04:32 and FileBot is picking up 02:32...

Thanks again,
Jeff

Re: Endless hourglass when trying to rename JPGs

Posted: 28 May 2025, 11:00
by rednoah
:?: How endless is the hourglass exactly? Have you tried a smaller batch of files to get a feeling for how fast / slow remote file system operations will be in your specific setup?

:?: Is there a progress dialog?

:idea: If there's an hourglass after clicking Rename but before the progress dialog then FileBot is likely preparing the move / copy file system operations, which may include other more simple file system operations (usually in the sub-millisecond range on a local file system) to check if the target file path already exists / needs to be overwritten, which needs to be done for all files ahead of time, which can be somewhat slow on 12k files on a slow remote file system.

:idea: If you're familiar with the command-line then you could consider running filebot on device which will speed up file system latency by many magnitudes. filebot-xpra is also an option if you need the GUI but also want to run locally on device.

Re: Endless hourglass when trying to rename JPGs

Posted: 28 May 2025, 11:01
by rednoah
ahrensjt wrote: 28 May 2025, 10:53 In Windows File Explorer, many files have a Date Taken of 2018-10-28... but FileBot is showing Date Created (oddly with a date of 2020-06-14).
:?: What does the MediaInfo Inspector say for the file at hand?

Screenshot



:!: I don't know if DNG files are supported. They might. They might not. I don't remember DNG files coming up before so I haven't done any tests one way or another.

Re: Endless hourglass when trying to rename JPGs

Posted: 30 May 2025, 13:12
by ahrensjt
rednoah,

Thanks for the replies - definitely appreciated. You brought up multiple topics, so I will segment my responses.

FIRST: I tried Renaming with just a handful of files in the GUI. It worked. So waiting 15 minutes was clearly not enough for the volume of files I was working on.
So it appears your were correct - just a LOT of processing required for so many files.
Per your recommendation, I will see if I can get my head around the CLI and use that. Thanks again.

SECOND: before executing using the CLI, I wanted to get the syntax tested.
I was unclear what data fields to use in a Preset, so I did a "matrix" of tests across File Types, Preset Data Source, and Variable.
Executive summary: I am not able to pull "Date Taken" using a Preset which matches what I see in Windows File-Properties.

Here is my testing...
File Types: two files each (10 total) from JPG, JPEG (just being pedantic), DNG, MOV, MP4. Note that almost all of these files are from Android or Apple phones.
Preset Data Source: Plain File, Extended Attributes, EXIF Metadata
Variables: I just want to use the CreatedDate+Time+Camera in the file name, so I tried "dt", "ct", "d", and EXIF data.

The table summary is here:
[img][https://drive.google.com/file/d/1fsqw5L ... sp=sharing]
I can load the Excel file if requested.
You can see that for all but one of my Presets, all but one of the JPG/JPEG/DNG files failed to pull the correct "creation date".
You said you were not sure about DNG... if I could just pull the File Property for Origin-Date Taken then that would work for me.

The Presets that I used are here:
[url][https://drive.google.com/file/d/1y8V3X8 ... sp=sharing]


Any suggestions on how I can just pull the "Date taken" correctly?

Thanks again,
Jeff

Re: Endless hourglass when trying to rename JPGs

Posted: 30 May 2025, 16:54
by rednoah
ahrensjt wrote: 30 May 2025, 13:12 Any suggestions on how I can just pull the "Date taken" correctly?
:?: Can you share one sample file? And the expected "date taken" for that file. Then I could have a look myself and run some tests to see if we can get there. Thought at a glance it looks like you already tried to get values via all the bindings.

:?: Have you tried other exif tools that can display the entire exif table? I can only assume the exif metadata has multiple values and different tools pick different value for some reason. The data you get via Windows Explorer presumably must be part of the file content somehow.

Re: Endless hourglass when trying to rename JPGs

Posted: 31 May 2025, 00:47
by ahrensjt
I will share the files this weekend. But I used ACDSee to inspect the files. It has a tab for FILE data, and a separate tab for EXIF data.
I added the result to the testing table.
[img][https://drive.google.com/file/d/1BmhtyN ... sp=sharing]

For the two DNG files, ACDSee correctly read the EXIF "DateTime Original" field.
For the two DNG files, there was a difference. In one file, ACDSee read the File "Created" and "Modified" fields I see in Windows explorer.
In the other file, these fields appeared as blank. In any case, I would prefer clearly to use the EXIF data in the DNG files.

For the two JPG files, ACDSee correctly read the EXIF "DateTime Original" field, and also correctly read the File "Created" and "Modified" fields I see in Windows explorer.
As with the DNG files, those File Date fields seem odd (Modified date is earlier than Created date), and the EXIF data would be preferred.

For the two JPEG files, ACDSee correctly read the EXIF "DateTime Original" field, and also correctly read the File "Created" and "Modified" fields I see in Windows explorer.
In this case, both of the File "Modified" dates appear to be the correct "taken" date.

It would be great to have FileBot be able to read this data - I will need to create different presets (or a more complicated script), but I'm still hoping for bulk renaming and "re-foldering".

Regards,
Jeff

Re: Endless hourglass when trying to rename JPGs

Posted: 31 May 2025, 10:27
by rednoah
I found a Pixel 6 to create a sample DNG file for testing myself:

Properties: Select all

New Subfile Type             : Full-resolution image
Image Width                  : 4080 pixels
Image Height                 : 3072 pixels
Bits Per Sample              : 16 bits/component/pixel
Compression                  : JPEG
Photometric Interpretation   : Color Filter Array
Make                         : Google
Model                        : Pixel 6
Strip Offsets                : 3306154
Orientation                  : Top, left side (Horizontal / normal)
Samples Per Pixel            : 1 samples/pixel
Rows Per Strip               : 964 rows/strip
Strip Byte Counts            : 200792 bytes
Planar Configuration         : Chunky (contiguous for each subsampling pixel)
Software                     : HDR+ 1.0.748116481zd
Date/Time                    : 2025:05:31 18:01:02
YCbCr Coefficients           : 299/1000 587/1000 114/1000
YCbCr Sub-Sampling           : YCbCr4:2:0
YCbCr Positioning            : Center of pixel array
Reference Black/White        : [0,128,128] [255,255,255]
Tile Width                   : 256
Tile Length                  : 256
Tile Offsets                 : [192 values]
Tile Byte Counts             : [192 values]
CFA Repeat Pattern Dim       : 2 2
CFA Pattern                  : [Green,Red][Blue,Green]
Exposure Time                : 8427809/536870912 sec
F-Number                     : f/1.9
Exposure Program             : Program normal
ISO Speed Ratings            : 586
Exif Version                 : 2.31
Date/Time Original           : 2025:05:31 18:01:02
Date/Time Digitized          : 2025:05:31 18:01:02
Time Zone                    : +08:00
Time Zone Original           : +08:00
Time Zone Digitized          : +08:00
Shutter Speed Value          : 1/63 sec
Aperture Value               : f/1.9
Brightness Value             : 0.217
Exposure Bias Value          : 0 EV
Max Aperture Value           : f/1.9
Subject Distance             : 0.138 metres
Metering Mode                : Unknown
Flash                        : Flash did not fire
Focal Length                 : 6.8 mm
Makernote                    : [2040 values]
Sub-Sec Time                 : 092617
Sub-Sec Time Original        : 092617
Sub-Sec Time Digitized       : 092617
White Balance Mode           : Auto white balance
Digital Zoom Ratio           : Digital zoom not used
Focal Length 35              : 24 mm
Subject Distance Range       : Macro
Lens Make                    : Google
Lens Model                   : Pixel 6 back camera 6.81mm f/1.9
Detected File Type Name      : ARW
Detected File Type Long Name : Sony Camera Raw
Expected File Name Extension : arw
So if we wanted to access that EXIF property directly from our custom format:

Properties: Select all

Date/Time Original           : 2025:05:31 18:01:02
We could do that like so:

Format: Select all

{ exif.'Date/Time Original' }

Code: Select all

2025:05:31 18:01:02

Format: Select all

{ exif.'Date/Time Original'.colon('-') }

Code: Select all

2025-05-31 17-01-02



:!: Note that Windows NTFS maintains a "Last-Modified" and a "Creation-Date" file attribute for each file. That is completely different and separate from the embedded EXIF metadata, but may be used as default value by Explorer / FileBot / etc when EXIF metadata is unavailable. The "Creation-Date" attribute notably refers to when the file was created which could mean when the file was create as a result of a copy operation. If you modify a file and then copy the file to a different folder, then the creation date will be after the last-modified date.

Re: Endless hourglass when trying to rename JPGs

Posted: 06 Jun 2025, 14:36
by rednoah
I did investigate the hourglass issue with >10k files on a slow SMB share and I was indeed able to reproduce the problem and find the cause. Before renaming FileBot does all kinds of sanity checks, check if the target file already exists, check if the source file still exists, check symlink targets, etc. These operations are usually instant on on a local drive, and still fast enough on a remote SMB share. But once there's >5k files in a single folder I did notice quite a bit of lag for each file system operation.

FileBot r10574 adds an additional progress monitor that will optionally popup when things seem to take longer than usual at this step of the process.

Re: Endless hourglass when trying to rename JPGs

Posted: 06 Jun 2025, 21:09
by ahrensjt
Thanks rednoah.

BTW I will be getting back to the a topic above to try your suggestions, but after a family vacation :)

Cheers,
Jeff