-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS Live Photo #16401
Comments
Please provide more info. Does it display correctly on the web? Is it still broken if you log out and back in? |
iOS Version 18.3.1 |
Are these files coming from external library as separate files? |
yes correct.. |
I have the same issue. For me the problem only shows up when I create the album structure using immich-folder-album-creator. The live photo gets separated with the same name. Snapshot saved my day |
Maintainer of said script here. I'm not familiar with live photos at all, so I cannot rule out it has something to do with the script. If I understand correctly, live photos are a still image (HEIC) and a video component (mov or HEVC). The only thing I can think of is that a problem might occur if only one of these assets are added to the album while the other is not, but Folder Album Creator does not differentiate on a file level, only on folder level. Also, I don't know if live photos are represented as a single asset in Immich or as multiple assets. |
and how could the folder creator cause this issue if pictures in a webbrowser showing correct? the web view does use the same albums |
I have the same problem -- but with my own script that creates albums. I have not conclusively tracked down the problem, but have noticed that the search api returns two assets for Live Photos, an image and a video. My script in turn (naively) adds each asset separately to the album. Maybe having both parts separately added to the album is tripping up the IOS app? |
@RobWW |
I also have this issue, it is still persistent with the current v1.128.0. I described the behavior in this issue. I feel that it definitely must be related to the creation of albums from external libraries, but I'm afraid I'm lacking programming experience preventing me to dig deeper into the cause of the problem. |
@Salvoxia When viewing a live photo (id': '02cb1ad1-395c-4985-a849-cc7037114df9), with the browser URL: Selecting the 3 dots -> Add to album produced only one api call: PUT: /api/albums/e731c42d-9e44-4026-b80c-8548cee8e7fe/assets I did not see any call for the video part of the file. As a quick test I removed all videos from all albums: for each assets with type VIDEO: for each album, remove the asset: This worked, live photos no longer have duplicate icons. However, for live photos my script had originally added to albums, I had to run several jobs: rescanning the external library, updating metadata, generating thumbnails and transcoding video to get the video part of the live photos to play without the error 'No video with supported format and MIME type found". (Live photos not in albums or added to albums with the web interface always played successfully.) I am not sure why this simple change was causing so much disruption, some documentation on managing live photos would really help. In terms of fixing the album script, I am not sure what best the solution is. The immich api easily maps from live photo images to the corresponding video (each image has a 'livePhotoVideoId' value that points to the video), but I cannot find a parameter in video files that indicate they are part of a live photo, and not just an independent video. |
The bug
Live Photos in iOS App not showing correctly. There are 2 files shown, one with an image and the other one is black with a "!" in it. On Safari and other web browsers live photo is shown correctly.
The OS that Immich Server is running on
Docker, Ubuntu 22.10
Version of Immich Server
v1.127.0
Version of Immich Mobile App
v.1.127.0
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
...
Relevant log output
Additional information
No response
The text was updated successfully, but these errors were encountered: