Immich/Screensaver: integrate into dashboard!

[cmmdmx]

First of all - what an awesome project! Just discovered it recently, and I'm already super hooked!

I was totally happy when I found out about the immich integration as screensaver.

New feature requests regarding immich/screensaver:

1. trigger screensaver manually from "overview"
2. option to toggle screensaver mode "object fit / object cover" to get real fullscreen photos (zoomed/cropped in)
3. current date/time still visible while screensaver is on! (maybe also to set on/off)
4. a tile on the overview page which can show the photos instead of just screensaver
5. optional, slow, subtle "zoom in" to give photos more live.

Just leave it here as ideas. Maybe that's inspiration for future releases!

[ulsklyc]

Thank you - glad it clicked. Let me go through the five, because they are not all the same size and two are closer than you'd think.

3. Clock while the screensaver runs - this is the one I'd do first. A photo frame that hides the time is the wrong trade for a wall-mounted tablet, which is where the screensaver mostly runs. Today only the photo's own date is drawn. Making it optional is right; the interesting question is whether it should follow the wall-mode clock settings rather than getting its own switch, so a household configures the time display once.

2. contain vs cover - object-fit: contain is hard-coded in screensaver.css. A per-household toggle is a small change. Worth saying out loud: cover crops, and on a portrait photo shown on a landscape screen it crops a lot - which is exactly why it is not the default. As an opt-in, fine.

1. Trigger manually from the overview - the mechanism already exists: preview() starts the screensaver on demand, it is just only wired to the settings page. Surfacing it elsewhere is mostly a question of where the control belongs, not of new machinery.

5. Slow zoom (Ken Burns) - possible, but it comes with a measured cost. #716 was exactly this: continuous motion plus a filter on a single element cost two thirds of the frame rate on modest hardware, and a wall tablet is modest hardware. If it happens it needs to respect prefers-reduced-motion and be off by default.

4. A photo tile on the overview - the biggest of the five and the one I am least sure about. The overview is the page that has to stay readable at a glance; a photo tile competes with everything around it for attention in a way the other four don't. Not a no, but it needs a design answer rather than a settings toggle.

No promises on timing - I'm keeping this open as the tracking thread for the screensaver as a whole rather than splitting it into five. If you end up wanting one of them badly enough to have a preference on the details, say so here and it moves up.

[cmmdmx]

Thank you for the feedback, I'm looking forward to see the results!
I can completely follow your analysis. Thanks!

[nomi25home]

Adding one more to this thread, since it's the screensaver's tracking discussion: a configurable idle delay before the screensaver starts.

Use case. I run Yuvomi on a dedicated wall photo frame (an old Android frame showing the dashboard full-screen). It's a display first and a touch device second - most of the day nobody touches it, and when someone does, it's to check one thing and walk away. Five minutes of a static dashboard before the photos come back is long on that kind of device; for us one minute is right. On a kitchen tablet that people actually work on, five minutes is probably still the better default, which is why I'd want it adjustable rather than just shorter.

Why I think it's small. public/components/photo-screensaver.js already reads the delay from the document:

const IDLE_MS = Math.max(30, Number.parseInt(document.documentElement.dataset.screensaverIdle || '300', 10)) * 1000;

but nothing sets data-screensaver-idle, so the 300 s fallback always applies. (PR #693 also described the timeout as "configured".) For now I'm setting the attribute on index.html at container start, which works but is obviously not something anyone else should copy.

What I'd propose, keeping in mind your note that the wall tablet's options should be configured once rather than gaining one-off switches:

• One household setting, "Start the screensaver after", with a few fixed choices (e.g. 1, 2, 5, 10, 15 minutes), default 5 so nothing changes for anyone who doesn't touch it, and the existing 30 s floor kept.
• Stored next to the other screensaver values in sync_config, with an optional IMMICH_SCREENSAVER_IDLE_SECONDS env var that wins over the database like the other Immich values. The client needs the value before the first idle period (/screensaver/photos is only called once the timer fires), so it would come from a small read on load - or the server could fill the data-screensaver-idle attribute the component already reads, whichever you prefer.
• Placement is the part I'd rather you decide: next to the Immich connection under Integrations, or with the wall mode settings if that's where the clock from point 3 above is heading.

If that direction works for you, I'm happy to open the PR - with all locales, tests and a CHANGELOG entry per CONTRIBUTING.md. Full disclosure as the guide asks: this comment and any PR would be drafted with Claude Code and reviewed by me.

Thanks for the screensaver in the first place - it's what made Yuvomi the right fit for the frame.

[ulsklyc]

@nomi25home You read the code correctly. The component takes the delay from data-screensaver-idle, nothing in the app sets that attribute, so every device waits the 300 seconds. The docs say "five minutes" for the same reason. The hook was left over from #693 and never got its other half.

On where the setting lives, your own example decides it, I think. A photo frame that should start after one minute and a kitchen tablet that should wait five are two devices in the same household. A household setting in sync_config gives both the same value, and so does an env var. The screensaver also runs on every signed-in device, phones included, so a household-wide "1 minute" would reach those too.

Wall mode had the same question and answers it per device: it is stored in the browser, because the wall tablet usually runs on a shared account and a server-side value would switch everybody's phone along with it. The idle delay is the same kind of value. So the direction I would take:

• A per-device choice, "Start the screensaver after", with the fixed steps you list (1, 2, 5, 10, 15 minutes), default 5, the 30 second floor kept.
• Stored in the browser like wall mode, and placed next to it under Settings → Account → Appearance. That also answers the placement question: it sits where the wall tablet is already configured, not under the Immich connection, which stays the household's part (server, key, album).
• No sync_config value, no env var, no read on load. The small script in the page head that already applies wall mode before anything renders can set the attribute the component reads, so the value is there before the first idle period.

Two details for a PR in that shape. The component reads the delay once when it loads, so a changed value should take effect without a reload. And the page-head script repeats its storage keys as literals, with a guard in the frontend audit that keeps them in step with their source - a new key belongs in both places.

The cost of this shape is that you set it once on the frame itself instead of at container start. For a frame without a usable keyboard that is one visit to the settings page; if that is a real obstacle on your device, say so, because it is the one argument for a server-side value.

If that works for you, a PR is welcome. Thanks for the disclosure and for reading CONTRIBUTING first.

[nomi25home]

@ulsklyc Thanks - per-device is the better shape, and your reasoning about phones convinced me. The PR is up in that shape: #1665.

• A "Start the screensaver after" select right after the wall-mode card under Appearance: 1, 2, 5, 10 or 15 minutes, default 5, 30 s floor kept.
• Stored in localStorage (yuvomi-screensaver-idle). No sync_config value, no env var, no read on load.
• theme-init.js sets data-screensaver-idle before any module loads. The key and the steps live in utils/screensaver-idle.js, and a guard in test-frontend-audit.js keeps the two in step, as you described.
• The component now reads the attribute on every arming and re-arms when it changes, so a new value applies without a reload.

On your open question: setting it on the frame itself is no obstacle. The frame is a touch screen running the app full-screen, so it's one visit to Settings. No need for a server-side value on my account.

I checked it in a headless browser against a real Immich album: the screensaver opens 60 s after load with "1 minute" chosen, and 60 s after switching from 15 to 1 minute without a reload. The details are in the PR.

[ulsklyc]

@nomi25home The idle delay is merged as #1665 - thank you for the work and for the patience through the review rounds. It ships with the next release; this thread stays open for the other screensaver points.