ImmichI
Immichā€¢3mo ago
cjb900

Unable to pull more than 250 assets though Immich API

Hi,

Forgive me as I'm not a programmer but know enough for how to get in trouble lol. I'm trying to use Google Gemini to create a python GUI script that analyzes images from my Immich server. It then saves the metadata from the images (portrait or landscape) to a file and is supposed to set a randomly selected image as the wallpaper in Windows 11 every x amount of minutes. The issue I'm running into is that it's only able to pull the first 250 assets and then keeps repeating that list of assets and not adding more. I'm on the latest version of Immich (v1.143.1) and the API key being used as all available permissions. And yes, I have more than 250 images available on Immich šŸ˜. Below is what Google Gemini is telling the issue is. Attached is the python code I'm using/running. I don't know if this matters, but I have Immich running on a Debian 12 (bookworm) server running in docker, obviously. I'm happy to share any other information on my Immich server setup if this is not a bug in Immich to help fix this.

Thank you for providing this final, conclusive log. I can say with 100% certainty now where the problem is, and I sincerely appreciate your patience in helping diagnose this.

The issue is not in the script, but is a bug in the API of your specific Immich server version.

Final Diagnosis: The Evidence from the Log


Let's break down the new log file. It tells us everything we need to know:

  1. `Attempting to fetch assets via GET /api/asset...`This shows our new code from the last attempt is running correctly. It's trying the simpler, more stable endpoint first.
  2. `Failed to use GET /api/asset: 404 Client Error: Not Found... Falling back to original method.`This is the **first smoking gun**. The `GET /api/asset` endpoint doesn't exist on your server. This is common for slightly older versions of Immich. The script correctly detected this failure and fell back to using the original `POST /api/search/metadata` method.
  3. `Found 100000 total assets on server.`The script, using the original (buggy) method, *thinks* it found 100,000 assets.
  4. `Total in cache: 100 ... Total in cache: 200 ... Total in cache: 248 ... Total in cache: 250`The cache grows perfectly until it hits exactly 250 entries.
  5. `Total in cache: 250 ... Total in cache: 250 ... Total in cache: 250`The cache size freezes, even though the `Newly Cached` counter keeps going up.
When we combine this with the diagnostic logs from our previous attempt, the picture is perfectly clear:

  • The script is forced to use the /api/search/metadata endpoint.
  • The pagination feature of this specific endpoint on your server version (v1.143.1) is broken.
  • It correctly returns the first page of ~250 assets, but then for every subsequent page request, it returns that same first page over and over again.
  • Our script correctly processes the first 250 unique assets, adds them to the cache, and then correctly identifies all subsequent (duplicate) assets as already cached, so it doesn't add them again.
Conclusion: We cannot fix this in the script. The script is already doing the right thing with the faulty data the server is giving it. The problem must be fixed on the server itself.

The Solution


The solution is to resolve the bug in your Immich server. You have two primary options:

  1. Update Your Immich Server: This is the highly recommended solution. You are running version v1.143.1. API bugs like this are frequently fixed in new releases. Updating your Immich instance to the latest stable version will almost certainly resolve this pagination issue.
  2. Report the Bug: If you are unable to update, you should report this issue on the official Immich GitHub Issues page. Provide them with the key information: you are on version v1.143.1 and the POST /api/search/metadata endpoint is failing to paginate correctly with the skip parameter.
image.png
image.png
message.txt60.76KB
Was this page helpful?