iOS: Unable to backup 1 asset with no name or ID but has Oct 4th, 2020 date
I tried searching GitHub and Discord for someone with a similar issue.
* Using Immich Server v1.140.1 on Synology NAS via Container Manager
* Using Immich iOS App v1.140.1 build 220
* Connected over LAN without SSL/TLS when on home WiFi, otherwise over a Cloudflare Tunnel via the internet
I set up Immich, used
immich-go to upload the massive historical library of my Google Photos pics via Takeout, and then installed Immich on my iPhone to get it to upload the Recents album to continue ongoing backups. With Takeout surely some pics on my iPhone were duplicates and skipped, no biggie.
But sadly after waiting for the first big iPhone backup to finish, it got stuck on a final asset that appears to have no name or ID. It stays stuck past forced-closing the app, and seems to hang the backgrounded backup task. The stuck asset did mention a date, so I checked on the Immich timeline itself, Google Photos app, my iPhone's Photos app, and my Mac's Photos app for any image on that date that would be the culprit. Alas no such image that isn't backed up exists.
Should I open a GitHub issue? iOS App's Finest grained logs doesn't give me any info, nor the troubleshooting toggle, when I tap "Backup" again to kick off the process. Zero pertinent logs from Immich server container.
31 Replies
:wave: Hey @HACKTHEPLANET,
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:I’ve had this EXACT same issue with the EXAXT same Oct 4, 2020 date!!!!!!
Thank god it wasn’t just me. The only way I got rid of it was when I upgraded phones and did not copy any assets over from the previous phone via iCloud. I haven’t seen it come back.
also, I purposely did not install Google Photos on my new iPhone because I thought there was a chance that it could have contributed on some deep level. Who knows.
Huh. Super weird. Glad to know it’s not just me. I reinstalled the iOS app again from scratch and got the same result
Can you try the beta timeline and backup?
Oct 4, 2020 is just a placeholder value I believe
But the backup has been totally reworked in the beta
What does view details say?
that's the second screenshot: blank
Can you force close the app, bring it back up, then grab the log after it finsihes syncing
And just to verify, you are currently over local ip correct?
Correct
currently at INFO level with troubleshooting disabled. Want me to go finer first?
Maybe try info first
I can share the logs if you wish
assuming this error is not a red herring
Note: in the non-beta timeline, there was no error in the logs when I started a foreground backup task
Do you use Icloud shared albums or anything like that?
Negative. My setup is as follows:
* Paying for iCloud+ and so my iPhone Photos are synced up to iCloud
* Google Photos up until recently (about 2-3 days ago I turned it off) would also sync from my iPhone device via their app
* Immich now also backs up the "Recent" iPhone album
I assume this means I have no Shared Albums enabled/used/setup/whathaveyou
I don't use Ios but I would assume. May have to wait for a mobile dev to chime in. My guess is it's a corrupted file or file with no extension, but not sure how to track it down
Happy to wait, would like to get to the bottom of it knowing I'm not the only one affected.
To me it seems like at least a diagnostic-level log to report files that cannot be "opened" by the code would be useful to track it down
And yeah, my guess is the same. There's a weird funky file somewhere on the device that's within one of the few folders/albums that "Recents" encapsulates and it's not actually a photo/video asset.
Every once in awhile I’ll see it pop back up. But at least it doesn’t get stuck on it now. I just saw a glimpse of it very briefly and then went away.
It is indeed a placeholder :dogekek:
This means that the single asset cannot be hashed so we cannot determine if it is still on the server or not. However, the counts should be reflected accordingly.
You should have more info into which asset is failing in the next release - #21546
Left some comments
Thanks. I've added the album name as well. I don't think we even need the assert statement anymore. I'll confirm it once and will remove it later in a separate PR.
Awesome thanks for being so speedy. I'm v curious to find out what my dangling asset is 👀
Heya! So im on the latest release now which mainlined the new beta timeline 1.142.1 build 224 (server on same version). My mystery asset is still stuck. Looks like with the enhanced logging we have the clue:
Weirdly I don’t have a “Videos” album as shown in the Apple Photos app. I wonder where I can find and track down this asset
Ha. Found the video asset. Was a dumb meme video in probably an odd codec format. Played in Photos app just fine
This is the codec information on the video (I airdropped it to my mac):
huge original filename too. I wonder if that has something to do with it:
I_love_dogs_so_much_Especially_ripped_off_leash_dogs_who_run_up_to_me_while_Im_walking_outside._The_peop...or_society_are_the_people_who_when_their_dogs_run_up_to_me_with_nefarious_plans_say_ROCKO_NO_COME_HERE_and_then_when.MP4I want to see the error that gets printed in the new implementation. It might provide more info as to why this is failing with the error code from iOS. Do you still have the asset on your device or have you moved it and removed it from the device?
It’s in the trash and if I restore it, it’ll reproduce the issue in Immich again
I can also give you the file if you wish
Can you zip the original and share it here then?
Yeah! Enjoy the stupid video 😅