Some Live Photos are Split (Again) #2744

Closed
opened 2026-02-05 06:57:51 +03:00 by OVERLORD · 9 comments
Owner

Originally created by @carloslockward on GitHub (Apr 4, 2024).

The bug

I have found another instance of bug #3228.

I setup Immich and used my phone to upload all the photos locally stored there, then i downloaded all photos from google photos using takeout and then imported them to Immich.

Live photos uploaded from the phone worked flawlessly but when the import from google photos happened an additional video file was added. Photos that where not on the phone but where on the google photos zip file did not become live photos and kept the photo and video file separated.

After reading issue #3228, I verified that all jobs where done and then tried to run metadata job but this did not fix the issue.

Here is an example (I don't mind showing the location since is an old picture and its not very specific):

image
image

As you can see both images have metadata and they share the same name(minus the extension), same location and same capture time. So I don't know why they wouldn't merge (perhaps MP4 is not supported?).

The OS that Immich Server is running on

unraid 6.12.9

Version of Immich Server

1.100.0

Version of Immich Mobile App

N/A

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

N/A

Your .env content

N/A

Reproduction steps

1. Set up Immich
2. Back up photos from phone app.
3. Download same photos from google takeout
4. Import downloaded photos from google take out.

Additional information

No response

### Tasks
Originally created by @carloslockward on GitHub (Apr 4, 2024). ### The bug I have found another instance of bug #3228. I setup Immich and used my phone to upload all the photos locally stored there, then i downloaded all photos from google photos using takeout and then imported them to Immich. Live photos uploaded from the phone worked flawlessly but when the import from google photos happened an additional video file was added. Photos that where not on the phone but where on the google photos zip file did not become live photos and kept the photo and video file separated. After reading issue #3228, I verified that all jobs where done and then tried to run metadata job but this did not fix the issue. Here is an example (I don't mind showing the location since is an old picture and its not very specific): ![image](https://github.com/immich-app/immich/assets/24941719/da035690-221f-43b0-9236-e0f4f9a99922) ![image](https://github.com/immich-app/immich/assets/24941719/9d2920b4-4fcd-42ee-b5db-835f166fa642) As you can see both images have metadata and they share the same name(minus the extension), same location and same capture time. So I don't know why they wouldn't merge (perhaps MP4 is not supported?). ### The OS that Immich Server is running on unraid 6.12.9 ### Version of Immich Server 1.100.0 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML N/A ``` ### Your .env content ```Shell N/A ``` ### Reproduction steps ```bash 1. Set up Immich 2. Back up photos from phone app. 3. Download same photos from google takeout 4. Import downloaded photos from google take out. ``` ### Additional information _No response_ ```[tasklist] ### Tasks ```
Author
Owner

@bo0tzz commented on GitHub (Apr 4, 2024):

Google takeout destroys the metadata on the files, which would probably include the information that links live photos. Did you upload the takeout files as is, did you use a tool to rebuild the metadata from the .json files, or did you use immich-go to upload them?

@bo0tzz commented on GitHub (Apr 4, 2024): Google takeout destroys the metadata on the files, which would probably include the information that links live photos. Did you upload the takeout files as is, did you use a tool to rebuild the metadata from the .json files, or did you use immich-go to upload them?
Author
Owner

@Ynng commented on GitHub (Apr 4, 2024):

I'm experiencing what seems to be the same issue #8508

@Ynng commented on GitHub (Apr 4, 2024): I'm experiencing what seems to be the same issue #8508
Author
Owner

@carloslockward commented on GitHub (Apr 4, 2024):

@bo0tzz I used Immich-go which, to my understanding, should rebuild metadata from the json files.

@carloslockward commented on GitHub (Apr 4, 2024): @bo0tzz I used Immich-go which, to my understanding, should rebuild metadata from the json files.
Author
Owner

@Ynng commented on GitHub (Apr 4, 2024):

@carloslockward
To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem.

If you delete the mp4 file then refresh metadata on the jpg, it should fix itself.

@Ynng commented on GitHub (Apr 4, 2024): @carloslockward To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem. If you delete the mp4 file then refresh metadata on the jpg, it should fix itself.
Author
Owner

@carloslockward commented on GitHub (Apr 4, 2024):

@carloslockward To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem.

If you delete the mp4 file then refresh metadata on the jpg, it should fix itself.

@Ynng This worked! I should mention that your PR (#8512) Also worked on making the video invisible(but this is not the ideal solution since this will keep the video on disk which is redundant if its already embedded in the jpg).

So i should probably open an issue on immich-go so that it ignores mp4 files that start with MVIMG since they are not needed.

@carloslockward commented on GitHub (Apr 4, 2024): > @carloslockward To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem. > > If you delete the mp4 file then refresh metadata on the jpg, it should fix itself. @Ynng This worked! I should mention that your PR (#8512) Also worked on making the video invisible(but this is not the ideal solution since this will keep the video on disk which is redundant if its already embedded in the jpg). So i should probably open an issue on immich-go so that it ignores mp4 files that start with MVIMG since they are not needed.
Author
Owner

@Ynng commented on GitHub (Apr 4, 2024):

@carloslockward To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem.

If you delete the mp4 file then refresh metadata on the jpg, it should fix itself.

@Ynng This worked! I should mention that your PR (#8512) Also worked on making the video invisible(but this is not the ideal solution since this will keep the video on disk which is redundant if its already embedded in the jpg).

So i should probably open an issue on immich-go so that it ignores mp4 files that start with MVIMG since they are not needed.

I'm glad it worked!
Regarding the video being redundant, my understanding is that immich relies on the video as a separate asset to work properly.

Regarding fixing immich-go, it's probably best that the cli uploads the mp4 only if a matching jpg is found.
If only the motion video mp4 is found it should be uploaded regardless

@Ynng commented on GitHub (Apr 4, 2024): > > @carloslockward To my understanding, the video is embedded inside the MVIMG jpg already, the separate mp4 file is useless and the culprit of the problem. > > > > If you delete the mp4 file then refresh metadata on the jpg, it should fix itself. > > @Ynng This worked! I should mention that your PR (#8512) Also worked on making the video invisible(but this is not the ideal solution since this will keep the video on disk which is redundant if its already embedded in the jpg). > > So i should probably open an issue on immich-go so that it ignores mp4 files that start with MVIMG since they are not needed. > > > > I'm glad it worked! Regarding the video being redundant, my understanding is that immich relies on the video as a separate asset to work properly. Regarding fixing immich-go, it's probably best that the cli uploads the mp4 only if a matching jpg is found. If only the motion video mp4 is found it should be uploaded regardless
Author
Owner

@carloslockward commented on GitHub (Apr 5, 2024):

@Ynng I have now found this:

Even with your changes and after refreshing metadata, some of the videos still show up:
image

Here is the metadata:
image
image

I noticed the images with this problem are only the ones taken with my Samsung phone. Pictures taken with the Oneplus do merge properly after importing.

Any idea why?

Also what could be a good way of filtering for .MP4 files that are less than 5s long so i can delete them all in one go.

@carloslockward commented on GitHub (Apr 5, 2024): @Ynng I have now found this: Even with your changes and after refreshing metadata, some of the videos still show up: ![image](https://github.com/immich-app/immich/assets/24941719/6fefacdf-78ca-4f80-ab67-e77b71b44c9c) Here is the metadata: ![image](https://github.com/immich-app/immich/assets/24941719/a40d7d12-40f2-45fd-b407-65438932b742) ![image](https://github.com/immich-app/immich/assets/24941719/56bf0657-9665-4553-a9b0-f12d2144ca04) I noticed the images with this problem are only the ones taken with my Samsung phone. Pictures taken with the Oneplus do merge properly after importing. Any idea why? Also what could be a good way of filtering for .MP4 files that are less than 5s long so i can delete them all in one go.
Author
Owner

@carloslockward commented on GitHub (Apr 5, 2024):

After a little more debugging I found out that the Video in question and the MotionAsset are not the same. Meaning that there are 2 assets that might be candidates for the motion photo. 1 Asset came when I uploaded the photo from the Immich phone app and the other came when I uploaded the full google takeout backup using Immich-go.

This is the function that finds the asset for the live photo.

  findLivePhotoMatch(options: LivePhotoSearchOptions): Promise<AssetEntity | null> {
    const { ownerId, otherAssetId, livePhotoCID, type } = options;

    return this.repository.findOne({
      where: {
        id: Not(otherAssetId),
        ownerId,
        type,
        exifInfo: {
          livePhotoCID,
        },
      },
      relations: {
        exifInfo: true,
      },
    });
  }

As you can see it only finds one (findOne)

I would suggest finding all the assets that match the query, pick the largest one to be the MotionAsset and then delete the other ones.

@carloslockward commented on GitHub (Apr 5, 2024): After a little more debugging I found out that the Video in question and the MotionAsset are not the same. Meaning that there are 2 assets that might be candidates for the motion photo. 1 Asset came when I uploaded the photo from the Immich phone app and the other came when I uploaded the full google takeout backup using Immich-go. This is the function that finds the asset for the live photo. ``` javascript findLivePhotoMatch(options: LivePhotoSearchOptions): Promise<AssetEntity | null> { const { ownerId, otherAssetId, livePhotoCID, type } = options; return this.repository.findOne({ where: { id: Not(otherAssetId), ownerId, type, exifInfo: { livePhotoCID, }, }, relations: { exifInfo: true, }, }); } ``` As you can see it only finds one (`findOne`) I would suggest finding all the assets that match the query, pick the largest one to be the MotionAsset and then delete the other ones.
Author
Owner

@Ynng commented on GitHub (Apr 5, 2024):

I'll take a closer look tonight but gut feeling tells me the code snippet you sent is for apple live photo, which is always stored as 2 separate files.

Regardless of the motion photo format, I believe immich always stores the motion video part as a separate hidden asset.

@Ynng commented on GitHub (Apr 5, 2024): I'll take a closer look tonight but gut feeling tells me the code snippet you sent is for apple live photo, which is always stored as 2 separate files. Regardless of the motion photo format, I believe immich always stores the motion video part as a separate hidden asset.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#2744