🎯Description of the issue
Apologies for long-winded background info, hopefully it helps for context. I am running a single personal website on v3.15.1 with a MySQL DB for which I uploaded many old albums into external S3 storage using the bulk uploader and SFTP. I'm finding that a lot of those old photos (from 1999 onwards) don't have the best file metadata or image exif data, and I'm trying to clean that up. For example, the image_date field looks like it pulls from the file's created date. Which is probably fine most of the time. But in this case, that date is May 15, 2020, since that must be when I copied a bunch of these files locally from various external hard drives, before uploading them to my Chevereto instance. The files' updated date is closer (probably when I must have transferred them off the camera or otherwise edited the photos 20 years ago), but many of them also have the desired date still in the image exif data (e.g., in the DateTime or FileDateTime JSON keys. I recognize that the exif data is going to be different for different cameras and isn't all that reliable, so I don't expect the chev software to behave differently in this regard.
As a result of Chevereto's use of the file's creation date, though, I get a lot of undesired effects when it comes to things like sorting by Most Recent/Oldest or even just the "cover photo" for each album (which is the first image, based on whichever file happened to be written first when I copied them from another hard drive). I thought I could get clever with a SQL query to replace the image_date and image_date_gmt values with the preferred values from the exifdata field, but that's when I discovered the roadblock: under the datefolders configuration, the image URLs are dynamically generated at runtime based on the image_date field, regardless of where the image was originally saved in storage. So, after updating the database with the new, correct dates, my instance will lose its connection to the affected images, since it's now looking for them in the wrong location.
Which brings me to my question: Can you think of any sort of solution to this problem? Is there any way for me to properly update the image_date field for each of these photos while still preserving the chevereto connection to those photos in their original storage location (i.e., make everything continue to work, I don't care about file URL, but just display the new image date and use it for sorting)?
▶🚶Reproduction steps
Chevereto uses the file date created as the image_date rather than the image's exifdata dates (when available), which means my date-based sorting is wonky.
📃Error log message
Apologies for long-winded background info, hopefully it helps for context. I am running a single personal website on v3.15.1 with a MySQL DB for which I uploaded many old albums into external S3 storage using the bulk uploader and SFTP. I'm finding that a lot of those old photos (from 1999 onwards) don't have the best file metadata or image exif data, and I'm trying to clean that up. For example, the image_date field looks like it pulls from the file's created date. Which is probably fine most of the time. But in this case, that date is May 15, 2020, since that must be when I copied a bunch of these files locally from various external hard drives, before uploading them to my Chevereto instance. The files' updated date is closer (probably when I must have transferred them off the camera or otherwise edited the photos 20 years ago), but many of them also have the desired date still in the image exif data (e.g., in the DateTime or FileDateTime JSON keys. I recognize that the exif data is going to be different for different cameras and isn't all that reliable, so I don't expect the chev software to behave differently in this regard.
As a result of Chevereto's use of the file's creation date, though, I get a lot of undesired effects when it comes to things like sorting by Most Recent/Oldest or even just the "cover photo" for each album (which is the first image, based on whichever file happened to be written first when I copied them from another hard drive). I thought I could get clever with a SQL query to replace the image_date and image_date_gmt values with the preferred values from the exifdata field, but that's when I discovered the roadblock: under the datefolders configuration, the image URLs are dynamically generated at runtime based on the image_date field, regardless of where the image was originally saved in storage. So, after updating the database with the new, correct dates, my instance will lose its connection to the affected images, since it's now looking for them in the wrong location.
Which brings me to my question: Can you think of any sort of solution to this problem? Is there any way for me to properly update the image_date field for each of these photos while still preserving the chevereto connection to those photos in their original storage location (i.e., make everything continue to work, I don't care about file URL, but just display the new image date and use it for sorting)?
- Can I utilize the image_path field (which is currently NULL for these items) and just generate the correct S3 path using the existing image_date values before updating them?
- If I switch the storage config from datefolders to direct, that won't help me for all of these existing photos, will it?
- I can't use the bulk upload tool to only update metadata, right? And anyway, that probably wouldn't help me because of the dynamic datefolder path problem; I'd also have to change the corresponding location of each file on S3, and that's just going to be beyond my capabilities and probably will introduce risk of something else breaking unintentionally.
- Is my only solution to delete all of the old albums, figure out a way to extract the dates I want from the image files' exif data, and then generate a proper metadata file to go with them when I re-upload? Obviously that's the last resort; I've got about 10,000 files uploaded so far, and uploading (or rather, processing) takes a while with my current server hardware setup.
▶🚶Reproduction steps
- Upload lots of old photos for which the file created date is recent and does not match the actual date photo was taken (which is available in exifdata).
- Bang head against desk upon realization that I'm stuck with a bunch of photos that, upon uploading, are organized much more poorly on chevereto than I had expected.
- Try to update the database by pulling image dates from exif data and replacing image_date in chv_images.
- Load albums and images, only to discover that image paths (thumbnails, images, download paths, etc.) are all dynamic at runtime, based on the image date, not the location where those files were originally created in storage on upload.
Chevereto uses the file date created as the image_date rather than the image's exifdata dates (when available), which means my date-based sorting is wonky.
📃Error log message
