#[Question / UX] Client app does not automatically re-upload missing assets after server restore

13 messages · Page 1 of 1 (latest)

wary bolt
#

Environment

  • Immich Server Version: 3.1.0
  • Mobile App Version: 3.1.0 build.3057 / Android

Describe the bug / unexpected behavior
After performing a server restore/rollback to an earlier backup state, the mobile app retains its local database state where assets taken after the backup timestamp are marked as "already backed up".

As a result:

  1. The server is missing photos/videos taken between the backup timestamp and the restore point.
  2. The mobile app shows these assets as uploaded and does not automatically trigger a re-upload.
  3. The server and client states remain out of sync indefinitely unless manual action (like turning backup off/on) is taken.
  4. I reset the database on the mobile device which solved the issue for me but meant that I had to re enter all config data / pangolin access tokens which I want to avoid for the rest of my family if possible.

Expected Behavior
I would expect the mobile app or server to perform a state reconciliation during periodic background syncs (e.g., detecting that an asset ID or hash registered locally does not exist on the server) and automatically queue those missing local assets for re-upload.

Questions

  1. Is this behavior expected, or should the app eventually resolve this delta automatically over time?
  2. Is there a recommended admin background job or client-side mechanism to trigger a full state reconciliation across all client devices without requesting users to manually reset their backup state?

Thank you for the amazing project!

vivid sparrowBOT
#

:wave: Hey @wary bolt,

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. :blue_square: 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.

mystic elbow
#

This is expected currently.

wary bolt
#

So only propee solution is to reset the mobile device Database, or is there any other workaround I could look at?

mint meadow
#

To me this sounds like a bug.

The client and server should in theory keep a log of the last time the device was connected. If they don't match then it should trigger something client side (or some other mechanism of keeping track).

It does get messy with things like iCloud so I can see this being a bigger task / unclear implementation method.

For now, any other workaround doesn't come to mind

mint meadow
mystic elbow
wary bolt
wary bolt
mystic elbow
#

I’m sure that already had been requested

vivid sparrowBOT
# wary bolt Environment - **Immich Server Version:** 3.1.0 - **Mobile App Version:** 3.1.0 b...

[Issue] Sync failure from Android 3.1.0 to Server 3.1.0 (immich-app/immich#30755), Similarity: 0.785
[Issue] Mobile photo backup keeps retrying already-uploaded assets (immich-app/immich#28576), Similarity: 0.758
[Issue] [BUG] Immich app continously reuploads images (immich-app/immich#3201), Similarity: 0.754
[Issue] Photos backed up on the background are displayed as not uploaded (immich-app/immich#9136), Similarity: 0.750
[Issue] Mobile app re-uploads existing photos after Storage Template Migration changes file paths (immich-app/immich#29627), Similarity: 0.750
[Issue] [Mobile] Permanent FOREIGN KEY constraint failure syncing assets from external library after pre-sync reset (immich-app/immich#30630), Similarity: 0.738
[Issue] Android App - Missing pictures on backed up folder (immich-app/immich#9134), Similarity: 0.738
[Issue] Sync status not updating correctly (immich-app/immich#13769), Similarity: 0.727
[Issue] Android app unable to update asset list from server (immich-app/immich#9018), Similarity: 0.727
[Issue] [BUG] Android app tries to backup already uploaded photos in a loop. (immich-app/immich#621), Similarity: 0.719

mint meadow
#

Don't think I see it in the quick list - unless this doesn't search FRs?

obtuse mirage
#

current workaround would be to logout.
I don't know if sync remote/local jobs in the app will do anything

wary bolt
obtuse mirage
#

logout is basically a clear all