timezone issue

[dsm1212]

I think maybe you can just add this to the doc unless you want to add support for TZ, but I noticed that sometimes the fetch loop doesn't find the files and it falls back to the full scan. The reason is that when searching for the files by date it is using start and end of each day in UTC, but the pics usually have their original time in some timezone. So morning or evening pics won't match the timerange calculated. The work around I found is to map your timezone into the container like this:

  - /usr/share/zoneinfo/America/New_York:/etc/timezone:ro
  - /usr/share/zoneinfo/America/New_York:/etc/localtime:ro

I've got a couple of actual bug fixes I never pushed but it looks like I am in sync with you so I'll create a PR soon.

[arehbein-git]

The timezone files you bind mounted into the container are specific to the host. So when you use different platforms the method varies. I think it is much better to implement the a proper time zone handling in the container.

…

Am 22.04.2022 um 04:58 schrieb dsm1212 ***@***.***>:  I think maybe you can just add this to to doc unless you want to add support for TZ, but I noticed that sometimes the fetch loop doesn't find the files and it falls back to the full scan. The reason is that when searching for the files by date it is using start and end of each day in UTC, but the pics usually have their original time in some timezone. So morning or evening pics won't match the timerange calculated. The work around I found is to map your timezone into the container like this: - /usr/share/zoneinfo/America/New_York:/etc/timezone:ro - /usr/share/zoneinfo/America/New_York:/etc/localtime:ro I've got a couple of actual bug fixes I never pushed but it looks like I am in sync with you so I'll create a PR soon. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[dsm1212]

A simpler fix might be available. My recent camera pics have the tz in the date field on the pics. as "-5:00" so if we just fix the strptime() call we can probably process the date correctly. I was thrown off because I have a lot of scanned images where I entered the date with no time like "1985-12-25 00:00:00". With no +/- hours at the end Plex assumes these are in GMT+0 and lists them as "1985-12-24 20:00:00" since I'm 4 hours off in the winter. Those are not fixed by setting the timezone as I've done. Ideally we should make the same assumption when we parse the date in pptag. I'll see if I can get this corrected.

[dsm1212]

There is not a perfect fix here. I found that plex must have addressed something in this area. I have photos with the time field containing the UTC date and if I copy that photo and let plex pick it up a second time the current plex takes the localized date. So a photo that lists "1998-04-07 00:00:00" currently shows in plex as "1998-04-06", but if I copy it plex picks it up and adds it as a new pic with the date "1998-04-07". I'm going to just try to get it right for the current plex behavior.

[dsm1212]

I have a set of changes that work pretty well now for the date lookup. There were really two changes. The timezone of the container should be set the same as plex in config.py and there is a change to try to get the timezone from the image. All my recent image files have it, but it will fallback to not having as it does now if it is missing.

There definitely was a bug at some point in plex not taking the capture dates correctly. Even now if I look at my images in plex web it is not showing them correctly. Even though it displays the capture date wrong on new files, the searching is correct. You can do the Plex Dance (google it :-)) to fix the old image files if you really want to.

I do have some other changes in this. I drop a lot of files at once from light room and sometimes I saw it stop processing. The issue was related to the oneshot timer. There were some cases where we reenabled that from within the timer thread. But that causes a race condition because the trigger would cancel the current thread and then try to start a new timer. I didn't see a good way around that so I removed the oneshot timer. I think what I have is the same behavior of processing after 120 seconds of idle. I changed the copy of the pending list to be an order preserving copy because when I add a LOT of files I don't want to process the last one entered first since plex might not have gotten to it yet. I actually saw that happen a couple times.

I also fixed a bug I had introduced where I removed an entry from a list I was iterating on and that would skip a file. It would get processed in the full scan though so it wasn't really skipped.

I will run a few more days and then submit a PR.