Memory feature (use_memory) fails silently with 500 error whenever memory_paths is non-empty

[achristofi-bot]

Describe the bug

llmvision.image_analyzer with use_memory: true fails immediately with a generic 500 Internal Server Error / "Server got itself in trouble" whenever memory_paths is non-empty, regardless of image size or format. The call succeeds normally when memory_paths/memory_strings are empty (use_memory: true with no memory configured is a safe no-op). No exception, traceback, or error of any kind is logged anywhere — not in the HA core log, not with custom_components.llmvision set to debug, not with homeassistant.helpers.service set to debug. The failure is silent at every layer I can observe.

Environment

• Home Assistant Core 2026.8.1, Home Assistant Green (aarch64)
• LLM Vision 1.7.1 (installed via HACS, confirmed latest release, confirmed main branch memory.py is unchanged from 1.7.1 in the relevant methods)
• Provider: OpenAI (gpt-4o-mini)

To Reproduce

1. Configure memory_paths / memory_strings on the LLM Vision Settings config entry (I edited .storage/core.config_entries directly, but the options flow should produce the same data shape) with at least one entry, e.g.:

   "memory_paths": ["/media/llmvision/memory/test.jpg"],
   "memory_strings": ["Test"]

2. Restart Home Assistant (needed to pick up the config entry change).
3. Call llmvision.image_analyzer with use_memory: true:

   {
     "provider": "<openai provider entry id>",
     "message": "Describe who or what is visible in this image.",
     "image_entity": ["camera.some_camera"],
     "store_in_timeline": false,
     "use_memory": true
   }

4. The call returns 500 Internal Server Error / "Server got itself in trouble" in under ~1.5 seconds. ha core check remains clean and Home Assistant Core itself stays up and responsive (/api/ returns {"message": "API running."} immediately after) — only that one request dies.

What I ruled out

I suspected this was an image-size issue at first (my first two reference photos were 3088x2316px, ~1.7MB JPEGs) and spent a while testing variations to isolate the cause:

Test	Result
2x JPEG, 3088x2316px, ~1.7-1.8MB each	Crashes (500, ~0.6s)
2x JPEG, 750x1000px, ~75-85KB each	Crashes identically (500, ~0.6s)
10x JPEG (mixed people), all 750x1000px or 1000x750px, 75-125KB each	Crashes identically
1x hand-built minimal PNG, 200x200px solid color, 433 bytes (pure Python zlib+struct, no PIL - verified it's a valid, openable PNG)	Crashes identically
memory_paths: [], use_memory: true	Succeeds normally (proper JSON response, 3-5s)

This rules out both image dimensions/file size and image format (JPEG vs PNG) as the cause. The only variable that matters is whether _update_memory() actually has to run _encode_images() against at least one real path.

Debug log output

With custom_components.llmvision at debug level, this is the complete output for a failing call — nothing follows the Memory(...) line, at any log level, ever:

DEBUG (MainThread) [custom_components.llmvision] Service call data: {...'use_memory': True}
DEBUG (MainThread) [custom_components.llmvision] Provider: <id>
INFO (MainThread) [custom_components.llmvision.media_handlers] Fetching http://.../api/camera_proxy/camera.xxx?token=... (attempt 1/2)
DEBUG (MainThread) [custom_components.llmvision.memory] Memory(['Test'], ['/media/llmvision/memory/test.jpg'], 0)

That last line is Memory.__str__ (memory.py line ~202), logged at the end of Memory.__init__, confirming memory_paths/memory_strings load correctly from the config entry and the object constructs fine. The 0 is len(self.memory_images) — expected, since encoding hasn't happened yet at that point. Per the call flow in __init__.py (e.g. line 698-699), the very next thing that should happen is await call.memory._update_memory(), which calls _encode_images(). Nothing from that point on is ever logged, at any level, in any logger I've tried (I also tried bumping homeassistant.helpers.service and the root logger, with homeassistant.core reverted afterward since it floods the log with unrelated bus-event noise).

Other things checked

• ha core check is clean before and after every test.
• HA Core does not crash or restart — confirmed via the Supervisor API being responsive immediately after the failing call.
• No OOM-killer or crash signal in dmesg around the time of the failing calls.
• Confirmed I'm on the latest LLM Vision release (1.7.1) and that main's memory.py has the same _encode_images/_update_memory logic (no error handling around the PIL calls in either).
• The rest of the integration works completely normally - camera fetch, vision analysis, timeline create_event, get_events, everything - it's specifically _encode_images/_update_memory in memory.py that fails silently.

Expected behavior

Either the memory feature works with valid image paths, or if something is failing inside _encode_images/_update_memory, the exception should surface as a normal HA service-call error (homeassistant.helpers.service "Error executing service" with a traceback) rather than a bare 500 with zero log output anywhere.

Happy to provide more diagnostics if there's something specific you'd like me to check - I wasn't able to get a Pillow/PIL REPL running directly in this environment to test _encode_images's PIL calls in isolation, so I can't rule out a Pillow-version-specific issue on this exact platform (Home Assistant Green / aarch64), but the fact that it fails identically across every size/format variation I tried suggests it's not simply "one bad image."