Immich not syncing with multiple iOS devices unless in foreground
Hi I recently setup Immich on unraid - everything is working correctly and the web side of things is perfect. There are some massive threading/slowdown issues with the iOS app but I won't get into that.
The issue I have is that I have 2 iPhones (mine and my wifes) and an iPad Pro that I own, that are all setup for foreground and background syncing (also enabled background ability in iOS settings) and are all set to backup our entire collection (around 100,000 photos in total) over 2 different user accounts. When we're inside the iOS app, we can see that things, whilst awfully slow to interact with due to the upload, are syncing fine. I can also verify that everything is syncing correctly up with web side of things and everything is a-ok. The problem we have is that as soon as the app is backgrounded, the syncing stops.
I know from reading various issues posted already about this, that iOS has a scheduler and that the syncing happens sporadically. However, to test this, we've left the background processes running for multiple days to test and not a single Photo or otherwise is synced up during the period. As soon as the app is foregrounded, syncing starts again... so on and so forth.
Is anybody aware of the issue and is anybody looking to fix this? I have a very long road ahead of me to keep our screens on whilst it completes the task otherwise and presumable we're going to have an ongoing issue getting this to work for incremental backups also?
App version on all devices: v1.126.3
Server version: v1.125.7
All devices using latest iOS 18.3 release
26 Replies
:wave: Hey @drewzh,
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
- Container Logs:
docker compose logs docs
- Container Status: docker ps -a docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
- Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
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.
Successfully submitted, a tag has been added to inform contributors. :white_check_mark:If ingesting a lot of assets it's recommended to basically keep the device open and just let it chug through. There's really no way around it.
As for background. It's really only meant for occasional here and there, you can try and get IOS to run the job more often by some of these steps: https://immich.app/docs/FAQ#why-is-background-backup-on-ios-not-working
How do other apps seem to get around this? I thought all apps were treated equal? I've tested and not a single photos is backed up over the course of 2 days so far... surely that isn't right? I've brought the app into the foreground a few times between those periods as well to try and 'kick it off again'
Other apps may chunk their uploads. Which even if a file doens't fully upload, it can pick it back up later and continue. Immich doesn't have this function yet. If immich doesn't finish the upload in the required time it just fails and will need to restart.
But really it comes down to IOS backgrounds are kind of a black box. My partners Iphone will sometimes do it then won't for days.
But really either way, for the initial ingest you are just gonna need to let immich be in the foreground and chunk through
I'm sat on the same network as the Immich server to uploads for super fast (milliseconds per upload rather than seconds) so I'd assume that even if they were uploaded as a whole, the time taken to upload a single image would be minuscule and thus not killed.
Playing devils advocate - How sure are we that isn't an overlap of the general consensus that IOS aggressively throttles background tasks VS what might actually be an actual code issue in the iOS app that's just going undiagnosed due to the aforementioned assumption that it's just iOS doing it thing?
I can work around the bulk upload issue for sure - there's ways in which I export it via privacy.apple.com etc to do that, but even there's not a single photo synced during the background process during the last 48 hours across 2 different users and 3 separate devices... I'm fairly certain I know what the outcome will be once I start to do incremental changes?
All I can say is android works perfectly fine and its basically the same code base. As soon as I take a photo it's uploaded for the most part.
There are still optimizations to be made that I am sure will help but all you can really do right now is what's listed in the FAQ
Is it react native/cordova/similar?
Mobile is written in flutter
I think the goal is to move to native background job handling in the future, but that's just not the current state of things
I presume it's closed source and I can't take a stab at it?
Totally open
https://github.com/immich-app/immich
Oh right wow - I didn't see that
If you actually would like to contribute, I would go and ask in #contributing once you have an idea. There's lots of discussion and work still being done around uploads so that would be the best place to ask. See here for chunking discussion: 1335005435744354395
That's really good to know - I'm not a flutter expert by any means, but I have 20+ years app years app dev experience.... I'll see if I can spot anything amiss with the logic (which whilst I know is stated to not be the issue here... you never know)
Never a bad idea to have more eyes 🙂
Can I just clarify - are you saying that it's entirely possible that even with background syncing enabled - Immich, currently, with the devs understanding of how background tasks work in iOS, may NEVER sync a single photo, ever?
I only ask because that's the behaviour I'm witnessing (and others have reported also)... but it just seems.... wrong, right?
I can't say one way or the other. All I have is my experience and it's basically hit or miss. Sometimes it works sometimes it doesn't.
Like I said I'm sure there's room for improvement and that is the ultimate goal, but that's kind of the current state
No problem, I appreciate your help anyway - I'll do some digging through the code when I get a moment
I'm sure moving to native Ios background tasks will help, and i think they were even recently revamped in IOS, but I am not a dev, so I can't comment on specifics
I need to get this running in a simulator to actually work out what's going on (i.e, before and after tests) - but I've checked out the repo and found a few improvements already to be done with the way the background tasks are handled. Specifically the registration should happen earlier, any previous tasks should also be cleared before registering new ones and the first run should probably happen sooner than what's been specified.
I'll do some testing when I get time and see if my changes improve things
Whilst I'm not familiar with flutter, I am somewhat familiar with swift and the code was luckily very easy to understand
🤞
Like I said, hop over to #contributing if you find / want to discuss anything. Just want to make sure no work is repeated 🙂
Will do cheers
In my iOS experience syncs happen a couple of times a day
Same app/server/iOS versions as you
iOS background works fine for me for day to day use. Obviously not a massive import
So I've narrowed down the issue a little. I noticed that users were getting iOS notifications indicating backup progress - this is something that I'd never seen before (confirming the background tasks weren't even initiating earlier)... until I deselected our main album (70,000+ pictures) and selected a relatively small one with a few thousand photos. Low and behold, the backup notifications are triggering and photos are being backed up.
With that said, it appears the background task that's scheduled is too slow... at least that's my theory. My code changes do bring the scheduling code into what seems to be recommended place (AppDelegate) and I'm explicitly cancelling the existing tasks before registering new ones, but whilst this seems more correct, I don't believe it will fix the background task itself. I suspect the issue might be more systemic than that and tied to the invocation time of the task. I haven't yet been able to AB test to see if my changes have made a difference.
I suspect that the background task is attempting to do something heavy like enumerate the entire album of photos and this is taking up the precious time window.
Also, separate to this particular issue of items not being backed up, the UI whilst backing up in the foreground was basically unusable. As soon as I stopped the foreground backup, the UI became responsive again. Now, using a much smaller album, the UI is snappy again (with continuous hiccups.... but still, usable at least). Has the backup routine itself not being ran in a separate thread?
Assuming both of those issues are related, maybe there's a locking issue when dealing with large albums, or just a deficiency in the way that large data sets are being processed (buffering/streaming needed?).
My swift/flutter skills are very weak though, so whilst I can take a look to see if there are any logic issues or performance issues (25 years as a dev), it might be out of the realm of my expertise/time I can commit. I'll try though at least as it's killing the experience of what would otherwise be perfect.
We always welcome a new pair of eyes, I think with the current implementation most of the speedups have been exhausted, there is work planned for a large overhaul not sure where that is coordinated, but check out #contributing
Thanks. Totally get the direction to use the contrib channel - just adding context to others that may drop by and wonder where this went. Any dev work I’ll continue to post there 👍