Incomplete or missing memories for 3 days after uploading past photos

[skatsubo]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

TLDR

Main issue.

1. Expected: new images show up in memories next day after adding past photos matching "on-this-day" criteria.
   Observed: those images will not show up in memories for next 3 days.

A few more issues (can be moved to separate Github issues if needed).

2. Expected: to refresh memories by triggering the generation job in web UI.
   Observed: this won't fix next 3 days.

3. Expected: memories are generated even if the Immich server is off during night (probably rare case).
   Observed: memories are not created.
   UPD: removing this after discussing with @danieldietzler

4. Memories on Jan 1st, 2nd, 3rd will not contain photos for the previous year (if generated 3 days in advance at the end of December of the prev year).

Details

Main issue 1: memories for next 3 days may become stale/incomplete after adding more photos for the past years.

Since Persistent Memories were introduced in 1.127.0 / PR (amazing!), the memories creation job generates them for +/-3 days around the current date (7 days total), BUT only if the memories were not generated for these days yet, right?

For example, let's assume the scheduled job run on July 1st midnight. It generates memories from June 28 till July 4
and records the fact in the system metadata table: memories-state: {"lastOnThisDayDate": "2025-07-04T00:00:00.000Z"}

If later on July 1st I add some new photos covering July 2 till July 5 from past years, then:

• new photos for July 2, 3, 4 will not appear in memories on those days
• new photos for July 5+ will appear in memories on those days

I guess this is a known fact among Immich developers and was done intentionally for the sake of performance/reliability:

• Creating memories for 3 days in advance - improves robustness of persistent memories generation
• Skipping already processed days - performance optimization

Issue 2: manual run of the generation job won't fix memories.

If I re-run the memories generation job, it will skip next 3 days - July 2, 3, 4 - code. So triggering the generation job does not fix memories on these days - contrary to one's expectations.
Workaround includes purging memories-state and memories in the database manually before running the job as described in #16484 (comment). This is kind of common knowledge among advanced Immich users as the link/advice typically appears after another confused user asks on Github/Discord/Reddit.

Issue 3: memories are not generated if the server is off during night.

Scheduled jobs cannot run at midnight when the server is off, so memories are not created. The job has to be run manually.
Indeed, this is expected from tech point of view. Just can be confusing at first.

Issue 4 (UPD): memories on Jan 1st, 2nd, 3rd will not contain photos for the previous year

Example for January 2026

• The generating job runs 3 days in advance at the end of December 2025 (Dec 29-30-31 for Jan 1-2-3)
• The job uses max year as "current year - 1", code:

  immich/server/src/repositories/asset.repository.ts

  Lines 215 to 219 in 25efba8

  	.fn('generate_series', [
  	sql`(select date_part('year', min(("localDateTime" at time zone 'UTC')::date))::int from assets)`,
  	sql`date_part('year', current_date)::int - 1`,
  	])
  	.as('year'),

• So it will cap years at 2024, thus excluding January 1,2,3 2025 from memories shown on Jan 1,2,3 2026.

Existing related issues

• Memories section is missing on both Web And Android #19194

Discussion

Is this correct description of the current behavior/implementation or did I miss/hallucinate anything?
Could you share your thoughts on the rationale, benefits, tradeoffs, possible optimizations to refresh memories for next 2-3 days?

Or maybe this belongs to a bigger plan/roadmap for memories? Could you share a doc/discussion link if there is one already? (I've seen some memories-related feature requests: #2836, #7437)

The OS that Immich Server is running on

Debian 12 Bookworm

Version of Immich Server

1.135.3

Version of Immich Mobile App

1.135.3

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

<Default>

Your .env content

<Default>

Reproduction steps

1. Upload images from the past years with date matching tomorrow's "on-this-day" criteria. (Example: if it's 2025-07-01 today then upload photos taken on 2024-07-02 or 2023-07-03)
2. Wait for the scheduled memories generation job or trigger it manually from UI.
3. Outcome: those new images will not appear in memories tomorrow or day after tomorrow .

Relevant log output

<Let me know if needed>

Additional information

No response

[danieldietzler]

Everything you wrote sounds correct. The reason we're generating a few days in advance is also that we can be a bit "lazy" about the grouping, i.e., also show assets that were on that day +- a bit. That matches Google Photos' behavior. If we were to only generate the memories for the next day we couldn't (easily) make sure you don't just see the exact same assets three days in a row.

As to the nightly jobs; this does not only apply to memory generation. Immich has a variety of nighty jobs it more or less relies on. In short, Immich is built to be running 24/7.

[skatsubo]

Thanks for quick reply and the explanation, Daniel. All clear about the nightly jobs.

Could you elaborate on this one about days in advance / grouping:

also show assets that were on that day +- a bit

Is that an idea for future implementations?
Currently memories seem to be precisely limited to one day. Though I might missed something. From code it looks like:

Generation

1. MEMORIES_CREATE job iterates over each target day and
2. MemoryService calls createOnThisDayMemories
3. Which calls AssetRepository.getByDayOfYear
4. Which selects all assets with assets.localDateTime matching the target day exactly
5. And MemoryService sets showAt / hideAt to target startOf('day') / endOf('day'), code

   immich/server/src/services/memory.service.ts

   Lines 54 to 57 in 25efba8

   	private async createOnThisDayMemories(ownerId: string, userIds: string[], target: DateTime) {
   	const showAt = target.startOf('day').toISO();
   	const hideAt = target.endOf('day').toISO();
   	const memories = await this.assetRepository.getByDayOfYear([ownerId, ...userIds], target);

Then fetching

6. Client calls /api/memories?for=<current time>.
7. Memories controller fetches memories/assets for the current day: showAt <= current time <= hideAt - limited at the day borders exactly.
   (Also nulls are allowed for showAt/hideAt, not sure about them. Is that the +/- margin you mentioned?)
   

   immich/server/src/repositories/memory.repository.ts

   Lines 32 to 44 in 25efba8

   	searchBuilder(ownerId: string, dto: MemorySearchDto) {
   	return this.db
   	.selectFrom('memories')
   	.$if(dto.isSaved !== undefined, (qb) => qb.where('isSaved', '=', dto.isSaved!))
   	.$if(dto.type !== undefined, (qb) => qb.where('type', '=', dto.type!))
   	.$if(dto.for !== undefined, (qb) =>
   	qb
   	.where((where) => where.or([where('showAt', 'is', null), where('showAt', '<=', dto.for!)]))
   	.where((where) => where.or([where('hideAt', 'is', null), where('hideAt', '>=', dto.for!)])),
   	)
   	.where('deletedAt', dto.isTrashed ? 'is not' : 'is', null)
   	.where('ownerId', '=', ownerId);
   	}

[danieldietzler]

Is that an idea for future implementations?

Yeah sorry I wasn't precise about this. Yes it is. Google does it

[jrasm91]

"On this day" queries used to run every time the user loaded/viewed memories, which made them more like a specialized query/view into the database. That's just not how we really want memories to work. Memories are going to be snapshots of some criteria, and they're not going to update automatically after the fact. I do agree that some of the UX is bad and should be changed/improved.

I'm going to close this issue, since everything is working exactly as designed, and the root issues are mostly related to the change in expectation around how memories work, combined with the lack of future work that is planned in this area. With that said, there is a plan to finish building some of the features that the recent changes were preparing for:

• a dedicated /memories page for memory management
• add the option to regenerate "on this day" memories for a specific day
• the option to delete a memory
• the option to save a memory
• the option to view saved memories
• the option to manually create a memory (on-this-day for September 12th)
• the option to share a memory