immich
immich copied to clipboard
[BUG] "People" view in iOS app only shows subset of photos for a given face
The bug
In the iOS app (on both iPhone and iPad), clicking on a person under the People section of the Explore view only shows photos/videos going back to a certain date (i.e., two years ago or so). whereas doing the same thing in the web app shows the full set of images for that person. These cutoff date seem to be the same across the iPhone and iPad apps, however the cutoff date is different for each person. I have tried logging out and logging back in to the iOS app, as well as deleting the app and reinstalling, but this did not resolve the issue.
The OS that Immich Server is running on
Pop!_OS 22.04 (Ubuntu 22.04)
Version of Immich Server
1.90.2
Version of Immich Mobile App
1.90.0 build.130
Platform with the issue
- [ ] Server
- [ ] Web
- [x] Mobile
Your docker-compose.yml content
version: "3.8"
#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#
name: immich
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
command: [ "start.sh", "immich" ]
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
ports:
- 2283:3001
depends_on:
- redis
- database
- typesense
restart: always
immich-microservices:
container_name: immich_microservices
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
# extends:
# file: hwaccel.yml
# service: hwaccel
command: [ "start.sh", "microservices" ]
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
depends_on:
- redis
- database
- typesense
restart: always
immich-machine-learning:
container_name: immich_machine_learning
image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
volumes:
- model-cache:/cache
env_file:
- .env
restart: always
typesense:
container_name: immich_typesense
image: typesense/typesense:0.24.1@sha256:9bcff2b829f12074426ca044b56160ca9d777a0c488303469143dd9f8259d4dd
environment:
- TYPESENSE_API_KEY=${TYPESENSE_API_KEY}
- TYPESENSE_DATA_DIR=/data
# remove this to get debug messages
- GLOG_minloglevel=1
volumes:
- tsdata:/data
restart: always
redis:
container_name: immich_redis
image: redis:6.2-alpine@sha256:80cc8518800438c684a53ed829c621c94afd1087aaeb59b0d4343ed3e7bcf6c5
restart: always
database:
container_name: immich_postgres
image: postgres:14-alpine@sha256:50d9be76e9a90da4c781554955e0ffc79d9d5c4226838e64b36aacc97cbc35ad
env_file:
- .env
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_USER: ${DB_USERNAME}
POSTGRES_DB: ${DB_DATABASE_NAME}
volumes:
- pgdata:/var/lib/postgresql/data
restart: always
backup:
container_name: immich_db_dumper
image: prodrigestivill/postgres-backup-local
env_file:
- .env
environment:
POSTGRES_HOST: database
POSTGRES_DB: ${DB_DATABASE_NAME}
POSTGRES_USER: ${DB_USERNAME}
POSTGRES_PASSWORD: ${DB_PASSWORD}
SCHEDULE: "@daily"
BACKUP_NUM_KEEP: 7
BACKUP_DIR: /db_dumps
volumes:
- ./db_dumps:/db_dumps
depends_on:
- database
volumes:
pgdata:
model-cache:
tsdata:
Your .env content
# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables
# The location where your uploaded files are stored
UPLOAD_LOCATION=/home/eamon/Pictures/library
# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release
# Connection secrets for postgres and typesense. You should change these to random passwords
TYPESENSE_API_KEY=XXXXXXXXXX
DB_PASSWORD=XXXXXXXXXX
# The values below this line do not need to be changed
###################################################################################
DB_HOSTNAME=immich_postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
REDIS_HOSTNAME=immich_redis
Reproduction steps
1. On the web app, click the Explore tab.
2. Click on any recognized person under People.
3. Note the earliest chronological image that shows up under this view.
4. On the iPhone or iPad app, click Search.
5. Click the same person as you did in the web app.
6. Observe that there are fewer images that show up for this person than in the web app, and the earliest chronological image for this person in the mobile app is from a later date than in the web app.
Additional information
No response
I too am having this issue since v1.89.0
(that's when I recently started my instance, issue may existed before than). In my situation I can see pictures of faceA
on both iOS and webapp back to 2007; where as faceB
I can see back to 2022 in the iOS app and 2010 in the wepapp. I've tried logging out and back in, removing and re-installing the app, and the issue remains the same. I'm currently on server version v1.90.2
I intend to update to the current build in the next couple days.
Indeed, noticed that a while ago after adding a lot of images from my library to immich. However, to me it looks like a cutoff only applies to people appearing on a lot of images. So, I have a feeling it's more about the number of images returned from the person filter search being limited on iOS.
Yep same issue. I agree, I don't think it's a date limit, seems more like a hard limit on number of images that are returned.
Can confirm it as well. Using 1.92.1.
I have the same problem, 1.92.0 ,both on andriod and ios , webui is going well . Only the most recent 1000 photos can be displayed.
The issue still persists on 1.93.2 build .135 on ios and server version 1.93.3
I'm seeing the same thing on Android 1.93.2 build.119 and server 1.93.3
Looks like no update. App version: 1.95.0 build.139 Server version: 1.95.1
I noticed the same thing. Server and Android App on 1.99 It only shows exactly 1000 images in the people view, even though more images are tagged. Problem is only present in the mobile app, not on the web. Is there a setting for this I am missing, or is it actually a bug?
@markusltnr Yes, we need to visit the API to see why it doesn't return all the assets
Ah just check it again, we have the query limit at 500 return assets because the way the mobile render is different from the web app, we still need to build pagination into this API call to optimized it for the mobile app
This bug still exists right ? I'm seeing an occurrence of limited picture for a given face on the app in iOS
Yes. The post above indicates that the root cause was identified but the pagination has not been built into the respective API yet.
Bug still exists with server and client v1.103.1
There's probably no need for people to keep reporting "bug still exists" until the devs have indicated they've fixed the issue. They're aware of it and will presumably update this issue when they've implemented a fix. At that point if the bug still exists it would be worth indicating as such :)
There's probably no need for people to keep reporting "bug still exists" until the devs have indicated they've fixed the issue. They're aware of it and will presumably update this issue when they've implemented a fix. At that point if the bug still exists it would be worth indicating as such :)
Oh, sorry, did i miss issue link where i can check it?
Problem presist in Android APP version 1.105.0 build.139 + Server version 1.105.1 One user in my server report that he can see all search results (by face) without the assests limit few days ago. I think it is depend on the APP version. After he update APP then the 500 or 1000 assets limit is applied. But I don't know which APP version he used before. For Android phone, we can downgrade the app by install specific version of .apk Any suggestion? which APP version can be temperory workaround?
Can we just edit the size (1000) in search service in mobile lib? Am I correct? https://github.com/immich-app/immich/blob/88d43383486825e1fab3f6cc87d4edf465ce253e/mobile/lib/services/search.service.dart#L74
Can we just edit the size (1000) in search service in mobile lib? Am I correct?
https://github.com/immich-app/immich/blob/88d43383486825e1fab3f6cc87d4edf465ce253e/mobile/lib/services/search.service.dart#L74
This would do the trick, I guess - but, seeing that all other views use pagination instead, it would much rather need a pagination solution, which in turn, is more complicated than changing this number :)
Still an issue as of July 2024 on iOS Server version 1.107.2 App version 1.107.1 build.162