exif_data_missing

[MBiesma]

Hi Cedric,

First I would like to say thanks for building this script! It's also great that it doesn't rely on Python for example!

I see you are using the "create date" in exiftool to determine in which year.month folder the image has to be moved. Now I have a lot of images which don't have the "create date" in exiftool so all these images gets moved to the error folder. It would be great if you can update the script to use "create date" as primary but if "create date" cannot be found it will use "File Modification Date/Time" as fallback so these images do get moved to a year.month folder.

If you need any help testing, please feel free to contact me!

Thanks in advance!

Mark

[Gulivertx]

Hi Mark,

Thank's for your feedback.

I understand your problem, but I'm not really happy to use modified date has a fallback. This because the image will be move to a year and month which not correspond about when the image was taken. For instance if you modify the image 6 month later, the image will be moved in the bad folder. This is why I decided to use exif data and not file modified date.

For my use case, I prefer to have these images inside error folder and move by hand than have them in a bad place.

I'm not sure and need to confirm it but bash command, ls or stat give the modified date only. I need to investigate a bit more if we can get created date.

[MBiesma]

Thanks for your quick reply!

I used the "File Modification Date/Time" with exiftool, not with ls of stat. But the output looks the same:

root@MBNAS:/volume1/CloudStation/DSPhoto/Upload_Mark# stat IMG_20230807_230527_exif_data_missing.jpg
  File: IMG_20230807_230527_exif_data_missing.jpg
  Size: 3702            Blocks: 8          IO Block: 4096   regular file
Device: fa00h/64000d    Inode: 21496293    Links: 1
Access: (0700/-rwx------)  Uid: ( 1024/   admin)   Gid: (  100/   users)
Access: 2023-08-26 22:19:03.569212662 +0200
Modify: 2023-08-07 23:05:27.000000000 +0200
Change: 2023-08-26 22:46:27.710910086 +0200
 Birth: -

root@MBNAS:/volume1/CloudStation/DSPhoto/Upload_Mark# exiftool IMG_20230807_230527_exif_data_missing.jpg
ExifTool Version Number         : 12.65
File Name                       : IMG_20230807_230527_exif_data_missing.jpg
Directory                       : .
File Size                       : 3.7 kB
File Modification Date/Time     : 2023:08:07 23:05:27+02:00
File Access Date/Time           : 2023:08:26 22:19:03+02:00
File Inode Change Date/Time     : 2023:08:26 22:46:27+02:00
File Permissions                : -rwx------
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
JFIF Version                    : 1.01
Resolution Unit                 : None
X Resolution                    : 1
Y Resolution                    : 1
Image Width                     : 434
Image Height                    : 89
Encoding Process                : Progressive DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 434x89
Megapixels                      : 0.039

[Gulivertx]

Ho ok! I thought you didn't have any exif data on some picture files.

Then the problem here is different...

Strange than your camera not fill the birth file date 🤔 Hmm in this case yep, it looks like the best way is to use the modified date.

Edit : do you have in your file the exif data : Modify Date ? Or only File Modification Date/Time ?

[MBiesma]

I do backup all my Whatsapp images so I think images received with Whatsapp don't always contain the "Create Date" in exif. So as a fallback you could use the "File Modification Date/Time" in exif, that seems to be the best fallback choice.

As an example, I now have 613 images that don't have the "Create Date" string in exif. But they all have the "File Modification Date/Time" string in exif:

root@MBNAS:/volume1/CloudStation/DSPhoto/Upload_Mark# exiftool IMG* | grep "File Modification Date/Time" | wc -l
613

[Gulivertx]

ok, thank's. Just commit a fix, but I didn't try it, could you make some tests ?

The fix : https://github.com/Gulivertx/synology-photos-auto-sort/commit/0fcbce72ac93e5a8ef3ced2817f9e0985b190266

[MBiesma]

Sorry for the late response, I get the following error:

/volume1/CloudStation/Synology/synology-photos-auto-sort-master/synology-photos-auto-sort.sh: line 204: syntax error in conditional expression
/volume1/CloudStation/Synology/synology-photos-auto-sort-master/synology-photos-auto-sort.sh: line 204: syntax error near `]'
/volume1/CloudStation/Synology/synology-photos-auto-sort-master/synology-photos-auto-sort.sh: line 204: `            if [[ -z ${DATETIME} ] && [ -z ${MODIFY_DATETIME} ]]; then'

[Gulivertx]

ouch, sorry, typo. Just push a new version, now it should work.

[MBiesma]

I get the following error:

Start process
640 files to process

mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
mv: target '202.jpg' is not a directory
etc. etc. etc.

[Gulivertx]

ho !!! Can you send me by email some images ? I need to make some test to debug the problem.

[Gulivertx]

@MBiesma ? possible to have some images ?

[Gulivertx]

close as I do not have any response back...