#iOS backup uploads downscaled variants of existing iCloud photos

20 messages · Page 1 of 1 (latest)

stuck flint
#

Hi, I’m planning a clean re-import of a large Apple Photos/iCloud library and would like to confirm the safest workflow before deleting the current Immich user.

Environment:

  • Immich Server v3.1.0, Docker managed with Portainer
  • Immich iOS app from the App Store
  • iCloud Photos enabled with “Optimize iPhone Storage”
  • Apple Photos library: 46,165 assets; originals are fully downloaded on a Mac

The current Immich library was first imported from a Parachute export. When iOS mobile backup of Recents was enabled later, Immich uploaded additional versions of some existing photos instead of treating them as duplicates.

Example:

  • Same image, capture timestamp and camera metadata
  • Existing import: IMG_7046.heic, 4032×2268, 1.8 MiB
  • iOS upload: IMG_7046.HEIC, 2364×1330, 1.1 MiB

Because the bytes differ, checksum deduplication understandably cannot match them. This appears similar to GitHub issue #29542, which describes iOS supplying a downscaled/rendered variant with a different checksum.

Questions:

  1. Is this behavior still known in server/mobile v3.1.0?
  2. If I delete the current Immich user and run a clean full backup of Recents from the iPhone, should I expect one stable upload per Apple Photos asset and the original/full-resolution resource?
  3. What is the recommended workflow for a one-time full iCloud Photos import followed by ongoing iOS backup when Optimize iPhone Storage is enabled?
  4. If I import Apple Photos originals from the Mac first, is iOS likely to upload rendered variants again later?

Mobile backup is stopped for now. I can provide app logs, exact mobile build number and more side-by-side examples if useful.

pastel kestrelBOT
#

:wave: Hey @stuck flint,

Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich immich.

References

#

Checklist

I have...

  1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time).
  2. :ballot_box_with_check: read applicable release notes.
  3. :ballot_box_with_check: reviewed the FAQs for known issues.
  4. :ballot_box_with_check: reviewed Github for known issues.
  5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy).
  6. :ballot_box_with_check: uploaded the relevant information (see below).
  7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable

(an item can be marked as "complete" by reacting with the appropriate number)

Information

In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:

  • Your docker-compose.yml and .env files.
  • Logs from all the containers and their status (see above).
  • All the troubleshooting steps you've tried so far.
  • Any recent changes you've made to Immich or your system.
  • Details about your system (both software/OS and hardware).
  • Details about your storage (filesystems, type of disks, output of commands like fdisk -l and df -h).
  • The version of the Immich server, mobile app, and other relevant pieces.
  • Any other information that you think might be relevant.

Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)

If this ticket can be closed you can use the /close command, and re-open it later if needed.

pastel kestrelBOT
stuck flint
#

Additional version details: Immich iOS app 3.1.0 build 11; server 3.1.0, shown as the latest version. Local-IP, reverse-proxy and browser troubleshooting do not appear applicable because this report concerns iOS supplying different binary representations of the same Apple Photos asset. I have not reset the app yet in order to preserve its current state and logs.

pastel kestrelBOT
vale cave
#

Are the different assets coming from a SharedAlbum?

sour mica
#

and / or edited assets, I think we've been backing the wrong resource for edited / optimized images monkaHmm

stuck flint
#

Confirmed: this exact asset is in the iCloud Shared Photo Library—not a Shared Album—and was contributed by another participant. Apple Photos on the Mac has the full asset at 4032×2268, 2.3 MB, with no clear indication that it was edited. Immich’s iOS upload was only 2364×1330, 1.1 MiB, while Optimize iPhone Storage is enabled.

Would this be considered an Immich iOS resource-selection bug for optimized or Shared Library assets? If so, is there already a fix or tracked issue?

Most importantly for my migration: would a clean full backup of Recents currently risk uploading downscaled resources for other Shared Library assets as well? Until this is fixed, is importing the originals from Apple Photos on the Mac the recommended workaround—and can iOS backup then be enabled safely for future assets without uploading alternative versions again?

vale cave
#

This is ios limitation of Shared Album, I’ve checked this previously on the Photos app and they don’t let you get the original file either

stuck flint
#

Just to clarify: this is not an iCloud Shared Album. It is an asset in the iCloud Shared Photo Library, contributed by another participant. Apple Photos on the Mac does have the full 4032×2268 resource. Are you saying that the iOS Photos framework cannot expose the original resource of another participant’s Shared Library asset, even though the Mac can download it? If so, is there any supported way for Immich to request the full iCloud resource, or is a Mac-based original import the only workaround?

vale cave
#

Yeah you can easily test it by trying access the same photo on your Photos app on iOS

#

Hmm I just take a look at this. I haven't tested the iCloud Shared Photo Library feature specifically, but we were using the same APIs that getting the asset from normal library and iCloud Shared Album, so if we cannot get the original files, then it is the limitation of the framework

stuck flint
#

Thank you both for looking into this so quickly—I really appreciate the help.

I tested the same asset on the same iPhone. The native iOS Photos app reports the Shared Photo Library asset as 9 MP, 4032×2268, 2.3 MB. Immich uploaded it as only 2364×1330, 1.1 MiB. So the full-resolution version is available in the iOS Photos app on this device.

I am not an expert and am mainly trying to understand the recommended migration workflow. My starting point is a very large iCloud Shared Photo Library used by several family members. All originals are fully downloaded in Apple Photos on a Mac. The goal is to migrate the existing library to Immich once and then use the Immich iOS apps for ongoing backup of new photos.

How would the Immich team recommend approaching this situation? Should the initial library be imported from the Mac, and if so, how can the iOS apps subsequently back up new photos without uploading alternative or downscaled versions of assets that were already imported? Or is there a different supported workflow for migrating a large iCloud Shared Photo Library to Immich?

I would like to avoid deleting and rebuilding the Immich library again until I understand the intended approach.

tawny garnet
#

The Apple photos report is not reliable here. You’ll need to offload the file from the iPhone and inspect on a desktop

sour mica
# stuck flint Thank you both for looking into this so quickly—I really appreciate the help. I...

This could also be an issue with the library we're using to fetch originals. But solving this is a bit more involved so as to not re-upload assets for existing users. We could use some help to confirm if this is actually an "us" problem or an apple problem. Would you be willing to help us troubleshoot this? I can get back to you with instructions on how to probably by Friday or at worst Monday

pastel kestrelBOT
# stuck flint Thank you both for looking into this so quickly—I really appreciate the help. I...

[Issue] Images that are both in my library and in an iOS shared album appear as duplicate in Immich (immich-app/immich#28129), Similarity: 0.809
[Discussion] [Feature] Advanced duplicate resolution options to prevent mobile re-upload loops (immich-app/immich#29832), Similarity: 0.707
[Issue] iOS backup may upload reduced Apple ProRAW DNG instead of full original RAW file (immich-app/immich#28602), Similarity: 0.691
[Discussion] Duplicate Low Res Images (immich-app/immich#6507), Similarity: 0.684
[Issue] iOS app repeatedly re-uploads corrupted / downscaled duplicate copies of the same asset (dedup never converges) (immich-app/immich#29543), Similarity: 0.664
[Issue] [BUG] Incorrect photo upload in ios (immich-app/immich#3419), Similarity: 0.660
[Issue] iOS App seems to have uploaded lesser quality pictures ? (immich-app/immich#28973), Similarity: 0.656
[Issue] iOS: Adding an already backed up photo to a selected album triggers a second upload (immich-app/immich#29997), Similarity: 0.652
[Discussion] [Feature] Backup only images starting from a particular date (immich-app/immich#4169), Similarity: 0.582
[Discussion] [Feature] iCloud Shared Library Control Parity (immich-app/immich#6478), Similarity: 0.582

sour mica
#

But if the issue is confirmed to be from our uploader, the best way to do the initial import is to use the Parachute export and to exclude the old albums from the iOS app

stuck flint
#

Yes, I would be happy to help troubleshoot this. Please send me the instructions when they are ready. I will keep the current Immich server and iOS app state unchanged, with mobile backup stopped, so the current state and any useful logs are preserved.

I can also transfer the specific test asset from the iPhone to the Mac if needed, but I will wait for your recommended transfer method so that iOS does not create another rendered version during export.

Thank you for also clarifying the proposed migration approach. I understand the current recommendation as using the Parachute export for the initial import and excluding the historical photo sources from iOS backup afterward. Once the cause is confirmed, I would appreciate exact guidance on configuring ongoing backup so that new personal and Shared Photo Library assets are uploaded automatically without re-uploading older variants or requiring a manually maintained album.

I can check back here tomorrow evening (Central European time) and continue with any troubleshooting steps that are available then.

stuck flint
#

Hi, just following up on the troubleshooting instructions you mentioned. I’m still happy to help determine whether this is an Immich uploader issue or an Apple limitation.

I have kept the current Immich server and iOS app state unchanged, with mobile backup stopped, as requested. Before rebuilding the library or starting a full iPhone upload, I would prefer to run the controlled test you recommend.

Please let me know when the instructions are available. Thanks again for looking into this!

sour mica
#

Hey, sorry for the delayed response. I can give you a branch to troubleshoot this within Immich, but that means you've to have XCode setup, have the app build and get it tested on your device which is a lot of work. We're started looking into this and have an idea as to where the issue is from