-
1. What is not working as documented?Probably related to #2320 but without GPS specifics. Probably When indexing .heic images, taken on iPhones with disabled GPS for camera, the Consequent issue: In #2320 (comment) it was mentioned, that photos are sorted by local times, not by UTC. So this is considered expected behavior? This leads to images, even having proper time offset, being displayed not in 'natural' order. For example, if there are 3 pictures (pls see visual example below): The order they are displayed in Photoprism will be: Pic3, Pic1, Pic2 (Newest first sort) For the Oldest first sort it would be: Pic2, Pic1, Pic3 The order they were taken in ‘real life’ is: Pic1, Pic2, Pic3 Still, it's probably better to keep time zone in the sidecar file correct. Cases, when sorting issue matters:
2. How can we reproduce it?
For the sake of the example, photos were taken on same device, however behaviour is consistent if photos were taken on several different iphones. 3. What behaviour do you expect?I would expect for pictures without GPS coordinates, but with time offset present, to have corresponding offset assigned. So for the example above it would be +02:00 for pic1 and pic3 and +01:00 for pic 2. Also, would expect pictures to be sorted by 'utc' time (meaning ‘local’ time +/- offset), so they will be ordered as the they were taken in real life. 4. What could be the cause of your problem?Allegedly Apple populates the exif data not in supposed way (see example below), so time offset is not embedded into If I’m looking at the right place (https://github.com/photoprism/photoprism/blob/release/internal/meta/exif.go), those tags are not being read from exif (also they are not mentioned in https://www.photoprism.app/kb/metadata). However, offset is embedded in Reduced exif for Pic1 ( Full exif:5. Can you provide us with example files for testing, error logs, or screenshots?Please see included archive with sample set. When they are being indexed, they are sorted like this: In GUI the date-time displayed is same as
I do understand that time offset != time zone, so this is expected representation in GUI. I would suggest assigning any of the corresponding named time zones for such images or have other ‘lettered’ timezones in addition to Z. Not sure if this would be a viable solution though. The sidecar .yml files created automatically for those images: Pic1Pic2Pic36. Which software versions do you use?(a) PhotoPrism Architecture & Build Number: (b) Database Type & Version: (c) Operating System Types & Versions: Host OS - Debian 11 (d) Browser Types & Versions: (e) Ad Blockers, Browser Plugins, and/or Firewall Software? (f) Haven’t tried with IOS 17 yet. 7. On what kind of device is PhotoPrism installed?I suppose this should not be hardware-dependent, but since this is required for import/indexing-related issues: (a) Device / Processor Type: (b) Physical Memory & Swap Space in GB: (c) Storage Type: HDD, SSD, RAID, USB, Network Storage: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 8 replies
-
|
@shagog Your request has been implemented and will be available with our next update, scheduled for today or tomorrow. We appreciate your help with testing these changes! :) |
Beta Was this translation helpful? Give feedback.
-
|
Got it, thanks! I've run rescan on the bigger dataset, it looks to me that everything works good so far. Videos and live photos were also handled correctly. I think this discussion could be marked as resolved. The GMT/UTC inconsistency doesn't bother me at all, so its fully at your discretion. |
Beta Was this translation helpful? Give feedback.
-
|
We could add a special UTC sort option for users with this requirement. It might be hidden by default, like the "random" sort order that's implemented but not documented. |
Beta Was this translation helpful? Give feedback.
-
|
Just one question: are hidden options only available for the search results? Tried to use the "random" option as query param If so, I would suggest a bit different approach: may be it could be an option in compose file (environment variable like Experimental flag, probably not documented one) that would alter the behavior of default Oldest/Newest sort options to use UTC (or "field that is supposed to be UTC")? I understand that it might be not so common requirement and if this approach is too much trouble - the hidden option like "random" would be great! |
Beta Was this translation helpful? Give feedback.
-
|
You would also need to change the creation and updating of the following indexes in the files table (unless you are okay with less performance and significant changes to the SQL queries): photoprism/internal/entity/file.go Lines 46 to 47 in c40bf9a |
Beta Was this translation helpful? Give feedback.
-
|
If I'm reading correctly, both lines photoprism/internal/entity/file.go Lines 129 to 131 in c40bf9a could be changed to case MySQL:
switch TimeSortingOption {
case UTCSort:
// Use pictures.taken_at field (assuming it is in UTC) if available, defaulting to taken_at_local if NULL
Log("files", "regenerate photo_taken_at",
Db().Exec("UPDATE files JOIN ? p ON p.id = files.photo_id SET files.photo_taken_at = CASE WHEN p.taken_at IS NOT NULL THEN p.taken_at ELSE p.taken_at_local END WHERE ?",
gorm.Expr(photosTable), updateWhere).Error)
default:
//Keeping taken_at_local, original request
Log("files", "regenerate photo_taken_at",
Db().Exec("UPDATE files JOIN ? p ON p.id = files.photo_id SET files.photo_taken_at = p.taken_at_local WHERE ?",
gorm.Expr(photosTable), updateWhere).Error)
}And for the SQLite photoprism/internal/entity/file.go Lines 140 to 143 in c40bf9a could be changed to smth like case SQLite3:
switch TimeSortingOption {
case UTCSort:
// Use pictures.taken_at field (assuming it is in UTC) if available, defaulting to taken_at_local if NULL
// Request below is not optimal, but not sure how to optimize it in SQLite
Log("files", "regenerate photo_taken_at",
Db().Exec("UPDATE files SET photo_taken_at = CASE WHEN (SELECT p.taken_at FROM ? p WHERE p.id = photo_id) as ta IS NOT NULL THEN ta ELSE (SELECT p.taken_at_local FROM ? p WHERE p.id = photo_id) END WHERE ?",
gorm.Expr(photosTable), updateWhere).Error)
default:
//Keeping taken_at_local, original request
Log("files", "regenerate photo_taken_at",
Db().Exec("UPDATE files SET photo_taken_at = (SELECT p.taken_at_local FROM ? p WHERE p.id = photo_id) WHERE ?",
gorm.Expr(photosTable), updateWhere).Error)
}(sorry in advance for ugly code, these are just rough drafts to illustrate the idea) |
Beta Was this translation helpful? Give feedback.
@shagog Your request has been implemented and will be available with our next update, scheduled for today or tomorrow. We appreciate your help with testing these changes! :)