simulot / immich-go

An alternative to the immich-CLI command that doesn't depend on nodejs installation. It tries its best for importing google photos takeout archives.
GNU Affero General Public License v3.0
1.2k stars 36 forks source link

Looks like timezone parameter is required sometimes #196

Closed mlucianoeze closed 6 days ago

mlucianoeze commented 3 months ago

Hello there! I'm trying to import a pretty big bunch of Google takeout zip files, and the first thing I stumbled upon is that the program crashes when I try to import them with this command:

immich-go -server http://localhost:2283 -key <the-api-key> upload -google-photos takeout-*.zip

This is the output:

immich-go  0.12.0, commit febf80e2acb58afd8a8abd76731eedcb0ab8ff80, built at 2024-03-10T20:33:05Z
Server status: OK
Ask for server's assets...
0 asset(s) received
Browsing google take out archive...
panic: time: missing Location in call to Time.In

goroutine 1 [running]:
time.Time.In(...)
        time/time.go:1167
github.com/simulot/immich-go/browser/gp.googTimeObject.Time({{0x400000f460?, 0x40a940?}})
        github.com/simulot/immich-go/browser/gp/json.go:87 +0xb8
github.com/simulot/immich-go/browser/gp.(*Takeout).addJSON(0x40000ec050, {0x4005bb1a80, 0x19}, {0x4005bb1a9a, 0x1c}, 0x400654e080)
        github.com/simulot/immich-go/browser/gp/googlephotos.go:174 +0x44
github.com/simulot/immich-go/browser/gp.(*Takeout).passOneFsWalk.func1({0x4005bb1a80, 0x36}, {0x7f49ce3198, 0x400017fc30}, {0x0?, 0x0?})
        github.com/simulot/immich-go/browser/gp/googlephotos.go:128 +0x4fc
io/fs.walkDir({0x57c520, 0x40000b3280}, {0x4005bb1a80, 0x36}, {0x7f49ce3198, 0x400017fc30}, 0x4005ff7998)
        io/fs/walk.go:73 +0x5c
io/fs.walkDir({0x57c520, 0x40000b3280}, {0x40000280a0, 0x19}, {0x57f350, 0x400611a040}, 0x4005ff7998)
        io/fs/walk.go:95 +0x24c
io/fs.walkDir({0x57c520, 0x40000b3280}, {0x4000022228, 0x15}, {0x57f388, 0x4004d44e40}, 0x4005ff7998)
        io/fs/walk.go:95 +0x24c
io/fs.walkDir({0x57c520, 0x40000b3280}, {0x400000e0c9, 0x7}, {0x57f388, 0x400654d700}, 0x4005ff7998)
        io/fs/walk.go:95 +0x24c
io/fs.walkDir({0x57c520, 0x40000b3280}, {0x577118, 0x1}, {0x57f120, 0x4000096800}, 0x4005ff7998)
        io/fs/walk.go:95 +0x24c
io/fs.WalkDir({0x57c520, 0x40000b3280}, {0x577118, 0x1}, 0x4005ff7998)
        io/fs/walk.go:122 +0x8c
github.com/simulot/immich-go/browser/gp.(*Takeout).passOneFsWalk(0x3ef5c0?, {0x57ef60?, 0x40000ec280?}, {0x57c520?, 0x40000b3280?})
        github.com/simulot/immich-go/browser/gp/googlephotos.go:90 +0x70
github.com/simulot/immich-go/browser/gp.(*Takeout).passOne(0x40000ec050, {0x57ef60, 0x40000ec280})
        github.com/simulot/immich-go/browser/gp/googlephotos.go:81 +0x104
github.com/simulot/immich-go/browser/gp.NewTakeout({0x57ef60, 0x40000ec280}, 0x4000038040, 0x40001600c0, {0x4000096060, 0x1, 0x1})
        github.com/simulot/immich-go/browser/gp/googlephotos.go:65 +0xec
github.com/simulot/immich-go/cmd/upload.(*UpCmd).ReadGoogleTakeOut(0x4000188000, {0x57ef60, 0x40000ec280}, {0x4000096060, 0x1, 0x1})
        github.com/simulot/immich-go/cmd/upload/upload.go:510 +0x74
github.com/simulot/immich-go/cmd/upload.(*UpCmd).Run(0x4000188000, {0x57ef60, 0x40000ec280}, {0x4000096060, 0x1, 0x1})
        github.com/simulot/immich-go/cmd/upload/upload.go:219 +0x94
github.com/simulot/immich-go/cmd/upload.UploadCommand({0x57ef60, 0x40000ec280}, 0x57d10?, {0x40000b4068?, 0x18?, 0x18?})
        github.com/simulot/immich-go/cmd/upload/upload.go:205 +0x58
main.Run({0x57ef60, 0x40000ec280})
        github.com/simulot/immich-go/main.go:80 +0x454
main.main()
        github.com/simulot/immich-go/main.go:47 +0x1b0

Judging by the error message missing Location in call to Time.In, it looks like it was expecting a timezone, so I tried the same command but with a tzdata timezone, and it looks like it's working now:

immich-go -server http://localhost:2283 -key <the-api-key> -time-zone=America/Argentina/Buenos_Aires upload -goo
gle-photos takeout-*.zip

I'm not sure if this solution is going to work yet, as this takeout is really big and I've been waiting for quite some time now, but at least it hasn't crashed instantly like it did just before.

Also, I've seen in the code that this timezone thing is per asset, right in line 174 (where it crashes originally): https://github.com/simulot/immich-go/blob/febf80e2acb58afd8a8abd76731eedcb0ab8ff80/browser/gp/googlephotos.go#L171-L182 Does this affect photos taken in different timezones? I don't know exactly how Google saves dates in an asset JSON file, but I think this question is worth asking.

If this fix ends up working, maybe you should consider making the parameter -time-zone mandatory, at least on these cases where it's needed. Let me know if you need any help with that :)

simulot commented 3 months ago

Your system doesn't provide default timezone understandable for immich-go. It happens sometime with some NAS, or with Windows (not always šŸ¤” )

The -time-zone=time_zone_name just informs the program with your time zone. It will be the default time zone for photos not having the timezone indicated.

You can start importing you takeout and break it quickly to check the result. You can relaunch the command later, the work will resume.

mlucianoeze commented 3 months ago

Oh, I see, good to know! Is it worth it to implement a more clear message like 'you need to specify a timezone' on these cases with a previous check? I could help with that if you need. I'm asking beforehand so you can decide what's best, maybe a warning in the readme file would be enough, or even this issue itself may help somebody else to solve this problem :)

simulot commented 3 months ago

The difficulty is to understand why this happens. The system get the local TZ when it starts. If it fails here, a nice message is displayed.

I have tested on a regular linux and windows without finding an issue. Could you tell more about your system?

b-Tomas commented 4 weeks ago

I just had the same issue (hey neighbour! šŸ‡¦šŸ‡· šŸ§‰ )

cat /etc/timezone 
America/Argentina/Buenos_Aires

Looks reasonable. Is it possible that the go utility being used doesn't support all timezones? I think it is worth at least suggesting in the readme to use the -time-zone argument (in this case, -time-zone=America/Argentina/Buenos_Aires).

The exact error I was getting (v0.16) was a little bit different in my case. Pasting it here to help people searching for it

./immich-go -no-ui -server=http://localhost:2283 -key=<mykey> upload -create-albums -google-photos take
out-xxx-001.zip 
immich-go  0.16.0, commit 7579f2577f5f24c1e6d3b266989112777332e868, built at 2024-06-02T09:25:25Z
. _ _  _ _ . _|_     _  _ 
|| | || | ||(_| | ā”€ (_|(_)
            v 0.16.0 _)   

panic: time: missing Location in call to Time.In

goroutine 16 [running]:
time.Time.In(...)
        time/time.go:1167
...
simulot commented 4 weeks ago

It's basically the same error.

Could you show what the command timedatectl outputs?

b-Tomas commented 4 weeks ago

Dual booter here, I had not realized that. It could be related, since I had to configure the clock to avoid the windows/linux clock conflicts

āÆ timedatectl
               Local time: Sat 2024-06-08 12:25:04 -03
           Universal time: Sat 2024-06-08 15:25:04 UTC
                 RTC time: Sat 2024-06-08 12:25:04
                Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
simulot commented 4 weeks ago

Thanks. Nothing bad.

What's the value of the TZ environnement variable?

b-Tomas commented 4 weeks ago

It looks like I have no TZ variable set in my shell (printenv | grep -i tz yields nothing relevant).

I haven't set it in my Immich .env file since I am using the default file downloaded by following the docker compose setup guide. I am reading its documentation and it looks like it should be set as a fallback for exif, but is not required.

Is it possible that is what is causing the issue?

simulot commented 4 weeks ago

No, it crashes when trying to infer the date of capture using the file name. Ex: 20111209_110308_6D4DBECF.jpg should give 2011/12/09 at 11:03:03 Local Time...

The localtime determination fails on your system.

Could you show what the command ls -al /etc/localtime returns?

b-Tomas commented 4 weeks ago

Of course

āÆ ls -al /etc/localtime 
lrwxrwxrwx 1 root root 50 Mar  3 22:03 /etc/localtime -> /usr/share/zoneinfo/America/Argentina/Buenos_Aires

Note that my OS is Pop!_OS 22.04 LTS

simulot commented 4 weeks ago

I see. The problem comes from the library lā€™m using to determine the timezone.

Basically, the library takes the file name of the /etc/localtime target, and split it in parts: /usr/share/zoneinfo/America/Argentina/Buenos_Aires gives

  1. America
  2. Argentina
  3. Buenos_Aires

and it keep 2 and 3 instead of 1, 2 and 3.

I'll fix the library ASAP. Thanks for your help

unclamped commented 1 week ago

Same issue here! America/Argentina/Cordoba. Que onda pibes y pibas? What a funny error

simulot commented 1 week ago

Not funny... Use the time-zone=time_zone_name parameter to provide your time zone.

This is corrected in the release to come.

unclamped commented 1 week ago

Not funny...

@simulot Look at it from the bright side, how many times does a bug in a software application unite random Argentinians on the internet? :smile:

simulot commented 1 week ago

Not funny because there is always something you haven't yet tested šŸ˜„

simulot commented 6 days ago

The latest release fixes this