immich-go group files with same filename but different extension/timestamp/exif as a live photo.

[raidolo]

Little background: I've always backed up my wife's photos using "DS Files" on my Synology NAS. The photos were archived in her home folder and the duplicated filenames were renamed to _1.extension, so nothing has been overwritten by DS Files. But, it can happen that you have a photo and a video with the same filename, of course one has a photo extension (JPG, HEIC, PNG) and the other is a video (MOV), you probably have taken the video in a different moment, because the file naming on the phones and cameras can be cyclical you ended up with the same filename. For instance I have two files, IMG_3223.PNG and IMG_3223.MOV. Different metadata, different timestamps/exifs.

username@hostname:/volume2/homes/username/photos$ ls -al IMG_3223*
-rwxrwxrwx+ 1 username users 34695688 Aug  1  2021 IMG_3223.MOV
-rwxrwxrwx+ 1 username users  2583316 Sep  3 19:08 IMG_3223.PNG

I've uploaded the files using immich-go passing the whole directory, and immich server just grouped the two files in a "live photo", even if a PNG would never be a live photo in any phone in the market.

I've done some tests too. The problem is with immich-go only when you use the command "upload . " or "upload directory/" it links the images with the same suffix as Live Photo. The issue is not present in immich-cli running in docker. If you use Immich-go and upload the single files like "upload file1.PNG file1.MOV" they appear as different assets in the web ui.

[simulot]

We can thank Apple for naming photos like IMG_1234... This doesn't help here.

There isn't universal rule for linking a photo with its movie... The EXIF data seams to be inconsistant across brands.
The match is done on the name of the file with some twists for android MP files.

Looking at the code, I thank I can add check the date of the capture as well.
Thanks for reporting that.

[raidolo]

I've opened a bug also in the Immich repo, but then I've found that the issue appears only with immich-go. Anyway they replied that there is an exif data with the Live Photo ID... I didn't check cause I didn't have exiftool at hand, but can you check how immich-cli link them automatically? Or is it immich_server?

[simulot]

You can close the issue in the immich repo

LivePhoto ID requires to read the file with exiftool to get it... and not all users have exiftool installed on their machine.

I'm not keen to implement this feature by myself to get it from HEIC and MP4 files. Using the name and the date could be a good compromise.

[raidolo]

Also, I don't know why the behavior is different if I give to immich-go the directory or the single files. With single file the assets are correctly different items in the server. Now I'm uploading everything once again using "upload *". In this case also the scan phase took a much longer time, but I hope that this time the upload will succeed. I had also issues with a lot of files in the first run, like corrupted images, but I've seen I had a problem with the server memory, I'll give you my feedback and in case I open a new issue.

[raidolo]

You can close the issue in the immich repo

LivePhoto ID requires to read the file with exiftool to get it... and not all users have exiftool installed on their machine.

I'm not keen to implement this feature by myself to get it from HEIC and MP4 files. Using the name and the date could be a good compromise.

Ok I got it. Let me know if you need my help to test any new commit. I'll let you know how this run goes...

[raidolo]

The import with "upload *" went beautiful. All the (not so many) live photos are correctly matched with the video. All the thumbnails have been correctly generated. Now my poor NUC is doing 29K jobs for face recognition :). Cheers.

[shaankhosla]

Hey, I'm running into this same issue (ticket here). How did you get this working? I'm uploading from Google Takeout so I'm using:

./immich-go -server=<redacted> -key=<redacted> upload -google-photos /Users/shaankhosla/Downloads/takeout-*.zip