These bugs should hopefully be reproducible.
IOS App ver: 4.6.1
Synology NAS PMS ver: 1.3.3.3148
I live in Australia (In UTC+10, but daylight savings makes it UTC+11 currently).
I recently went on holiday to a UTC+8 area and took a bunch of photos and had IOS upload them back to the PMS each day.
Worked just fine and dandy. However, when I got home the phone uploaded all the photos again with adjusted filenames.
For example: A photo taken, named and originally uploaded as 2016-12-17 09.05.47.JPG, while in the UTC+8 timezone gets a duplicate copy named 2016-12-17 12.05.47.JPG now that I’m home in UTC+11 again.
If you look inside the details of each file, the EXIF date taken field has the correct value in both files. Perhaps this should be read to determine the filename instead of the timestamp of the file?
Also when taking a bunch of photos in burst mode, such that there are several photos a second, the upload copies all of these up to the server, but due to the renaming, they all get overwritten and only the last image is preserved in Plex. It may be wise to add a sequence number field to the tail of the filename in this instance so that these extra photos can be retained. Or possibly append the original filename on the tail.
Alternatively, an option to simply retain the original filenames and not rename at all would be appreciated.
Letting you know, we’ve found another inconsistency in the 4.6.1 version of the app.
I’m going to acknowledge this as a ‘need to investigate further’ if you’re ok with that? I wish to do so because the issue we’re tracking is also date/time related.
I would like to follow up my previous by asking if you have an example (can extract one pair of duplicated photos) from your library and hold them so they can be ready for the devs? I know they’ll come asking.
I would think that it would be fairly easy to replicate though.
Set IOS device timezone to non-home zone, a few hours difference.
Take some photos.
Camera upload them.
Return the device to the home timezone.
Camera upload again.
How I would deal with it is by keeping a small database of the photos present on the device and simply flagging that they’ve been successfully uploaded once. The overhead of that would be better than the network overhead of scanning the Plex server each time an upload cycle is required surely.
This wouldn’t truly address the case of photos taken in timezone A, but not uploaded until back in timezone B. They’d end up with the wrong timestamp … but at least there’d be no duplicates.
Another advantage of this is that unwanted photos could be removed from the Plex library without camera upload re-uploading them on the next cycle.
It would make camera upload less of a sync service and more of a once off copy service, but that may be preferable in many ways.
the date/time stamp is the EXIF data in the file. That’s one question which was asked. Is it GMT or is it local time? Along with how they account for such timezone translations. The ‘ultimate theoretical’ will come up too. “What happens when you cross the international date line and it’s ‘yesterday’ again ?”
Timezones are always fun.
The EXIF Date Taken field contains local time.
EXIF version 0221.
IOS 10.2 and 10.1.1
No mention of timezone in EXIF that I can see.
I have not played with photography since film was a new invention.
If EXIF is local time, there is no way for PMS to know otherwise, is there? I might take the photos in Berlin, fly home to the US, then upload them. The iOS app will not know which timezone they were taken unless there is also LAT/LON information (geotagging).
Absolutely could be tricky.
There must be some reference that the app is picking up though as the initial upload while in timezone A is using the true timestamp, but the upload from the home timezone is consistently 3 hours out, in my case. So it’s being influenced by timezones without being aware of it.
So I don’t think the app is using EXIF at all, it’s probably using the file system create date, which being Linux based, will be stored effectively as UTC but displayed as the correct local time.
The app could probably determine the home timezone by querying the server. The app could also find the difference between EXIF time and file create time and work out the timezone difference that way …
I think that’s just going to get complicated quickly though with little gain to be made. As long as the filename is based on the local time the photo was taken and duplication can be prevented, then I’d be very happy.
I see where your thinking is going but there’s a couple issues.
The app only reads the photos and date/time (even if just the date/time iOS wrote them (which might be even better if this were GMT)
Determining file name ‘time’ is the really tricky part. You take a photo, in Times Square, NYC, at 12:00:02 and then return home two days later to upload to your server. Is it “00:00:02” or is it “21:00:02” or is it UTC “05:00:02” ?
ultimately, if EXIF is local time, and deconfliction managed to permit all photos, including burst-mode, it should be good using the ‘wherever taken’ local time.
I believe this behavior still happens with app version 6.3 (from TestFlight), and has caused the duplicate upload of thousands of images when (my wife and) I moved between timezones.
Is this bug still being tracked? Is there any progress toward fixing it?
