immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Immich search API returns Apple Live Photos as two assets #5603

New Issue
Closed
opened 2026-02-05 11:35:36 +03:00 by OVERLORD · 4 comments
OVERLORD commented 2026-02-05 11:35:36 +03:00
Owner
Copy Link

Originally created by @RobWW on GitHub (Mar 11, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

As currently implemented, the Immich search API endpoint (api/search/metadata) returns two assets, an image and a video file, for each Apple Live Photo. This results in most scripts using the API treating these files as separate assets. It appears Immich does not expect the video component of Live Photos to be directly modified, and scripts doing so have been found to be the root cause of problems with Immich, such as Live Photos being shown as two separate assets in the IOS app:

See: https://github.com/Salvoxia/immich-folder-album-creator/issues/128 and https://github.com/immich-app/immich/issues/16401
Also see: https://github.com/immich-app/immich/issues/2665

Edit: This problem also causes Live Photo's to be split in the Immich Android app (https://github.com/immich-app/immich/issues/16401#issuecomment-2718905332)

This design is also the likely cause of this problem with the Immich android TV app: https://github.com/giejay/Immich-Android-TV/issues/109

The direct solution would be to only return the image part of the live photo from the api, at least with the default search parameters. This solution still returns the video asset ID, through the Image livePhotoVideoId property.

Contributing to this problem, currently the api does not provide a direct way of determining if a video file is part of a Live Photo. The only way I can see to do this is to get all assets, make a list of all livePhotoVideoId values, and for a video check if its asset ID is in this list. This process is obviously inefficient, especially for large libraries.

The OS that Immich Server is running on

N/A

Version of Immich Server

All recent versions

Version of Immich Mobile App

All recent versions

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

N/A

Your .env content

N/A

Reproduction steps

  1. Add Apple Lives Photos to Immich
  2. Get assets from the API: api/search/metadata

...

Relevant log output

Additional information

No response

Originally created by @RobWW on GitHub (Mar 11, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug As currently implemented, the Immich search API endpoint (api/search/metadata) returns two assets, an image and a video file, for each Apple Live Photo. This results in most scripts using the API treating these files as separate assets. It appears Immich does not expect the video component of Live Photos to be directly modified, and scripts doing so have been found to be the root cause of problems with Immich, such as Live Photos being shown as two separate assets in the IOS app: See: https://github.com/Salvoxia/immich-folder-album-creator/issues/128 and https://github.com/immich-app/immich/issues/16401 Also see: https://github.com/immich-app/immich/issues/2665 Edit: This problem also causes Live Photo's to be split in the Immich Android app (https://github.com/immich-app/immich/issues/16401#issuecomment-2718905332) This design is also the likely cause of this problem with the Immich android TV app: https://github.com/giejay/Immich-Android-TV/issues/109 The direct solution would be to only return the image part of the live photo from the api, at least with the default search parameters. This solution still returns the video asset ID, through the Image livePhotoVideoId property. Contributing to this problem, currently the api does not provide a direct way of determining if a video file is part of a Live Photo. The only way I can see to do this is to get all assets, make a list of all livePhotoVideoId values, and for a video check if its asset ID is in this list. This process is obviously inefficient, especially for large libraries. ### The OS that Immich Server is running on N/A ### Version of Immich Server All recent versions ### Version of Immich Mobile App All recent versions ### Platform with the issue - [x] Server - [ ] Web - [x] Mobile ### Your docker-compose.yml content ```YAML N/A ``` ### Your .env content ```Shell N/A ``` ### Reproduction steps 1. Add Apple Lives Photos to Immich 2. Get assets from the API: api/search/metadata 3. ... ### Relevant log output ```shell ``` ### Additional information _No response_
OVERLORD commented 2026-02-05 11:35:39 +03:00
Author
Owner
Copy Link

@Salvoxia commented on GitHub (Mar 12, 2025):

I'm not sure if the search returning both components of live photos should be seen as a bug (at least I like being able to find every asset via the search), but both mobile apps don't seem to be handling these two components of a live photo correctly.

@Salvoxia commented on GitHub (Mar 12, 2025): I'm not sure if the search returning both components of live photos should be seen as a bug (at least I like being able to find every asset via the search), but both mobile apps don't seem to be handling these two components of a live photo correctly.
OVERLORD commented 2026-02-05 11:35:39 +03:00
Author
Owner
Copy Link

@RobWW commented on GitHub (Mar 13, 2025):

In terms of retrieving both components of the live photos, the current API provides this: the image asset id is returned directly, and the video asset id is returned in the image livePhotoVideoId property. Both types of information are returned in one search, no additional calls are needed.

This design actually seems quite elegant. The Live Photos create edge cases that can be hard to test for (see https://github.com/Salvoxia/immich-folder-album-creator/issues/128). When accessed through the livePhotoVideoId property only programs or scripts that are aware of the additional video component will be exposed to it.

All the problems described above are cases where the video component of Live Photos should not have been handled separately, I suspect this is by far the most common use case.

@RobWW commented on GitHub (Mar 13, 2025): In terms of retrieving both components of the live photos, the current API provides this: the image asset id is returned directly, and the video asset id is returned in the image livePhotoVideoId property. Both types of information are returned in one search, no additional calls are needed. This design actually seems quite elegant. The Live Photos create edge cases that can be hard to test for (see https://github.com/Salvoxia/immich-folder-album-creator/issues/128). When accessed through the livePhotoVideoId property only programs or scripts that are aware of the additional video component will be exposed to it. All the problems described above are cases where the video component of Live Photos should not have been handled separately, I suspect this is by far the most common use case.
OVERLORD commented 2026-02-05 11:35:40 +03:00
Author
Owner
Copy Link

@RobWW commented on GitHub (May 29, 2025):

Closing. My testing shows that this issue is fixed in v1.133.0.
Thanks!

@RobWW commented on GitHub (May 29, 2025): Closing. My testing shows that this issue is fixed in v1.133.0. Thanks!
OVERLORD commented 2026-02-05 11:35:41 +03:00
Author
Owner
Copy Link

@thorsten-hehn commented on GitHub (May 31, 2025):

Can confirm that the issue with the split live photos does not exist any more (see this comment). Great work, thanks a lot!

@thorsten-hehn commented on GitHub (May 31, 2025): Can confirm that the issue with the split live photos does not exist any more (see [this comment](https://github.com/immich-app/immich/issues/16401#issuecomment-2907910900)). Great work, thanks a lot!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#5603
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?