[Feature] Exhaustive shuffle without repeats across the full eligible asset pool

[Kyomorie]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

I'd like an optional slideshow mode that guarantees an asset is not repeated until the full eligible asset pool has been traversed once.

My use case is a long-running digital photo frame with a filtered library.

As I understand the current behaviour, Kiosk already avoids immediately reusing assets from its current fetched/cache batch by removing displayed assets from that cache. However, once that batch is exhausted and a new random batch is fetched, previously displayed assets can become eligible again even though other assets from the complete matching library may not have been shown yet.

What I am looking for is an exhaustive shuffle across the full set of assets matching the current sources and filters:

1. Determine the complete set of currently eligible assets.
2. Show those assets in a random order.
3. Do not show an asset again during that cycle.
4. Only after the complete eligible set has been shown, start a new shuffled cycle.

For example, if 5,000 assets match the current configuration and Kiosk fetches assets internally in batches of 1,000, I would still like all 5,000 assets to be shown once before any of them becomes eligible for a repeat.

This should be optional so the existing random/cache behaviour can remain unchanged.

For splitview layouts, both assets displayed on a slide should count as shown for the current cycle.

This is related to #488, where the expected behaviour was described as choosing images "without repeats until all images have been displayed". However, that issue was closed after fixing a configuration problem and, as far as I can tell, did not add an exhaustive shuffle across the complete eligible asset pool.

I'm currently using Immich Kiosk v0.43.2 as a digital photo frame with person/date filtering.

[guillaumemichel]

+1. A related case: a large album combined with memories, where the number of memories varies daily (from about 1% to 10% of the album's size). I'd like every photo to be shown with equal probability, whichever source it comes from.

With the current log weighting (assetWeight), small sources are strongly favoured per asset. With a 500-photo album:

Memories	Share of slides	Proportional share	Each memory vs. each album photo
5	22%	1%	29× as likely
20	33%	4%	12×
50	39%	9%	6×

memory_weight can't fix this with a single value: equal probability would need ~0.03 to ~0.16 depending on that day's memory count.

An exhaustive shuffle across all sources, as proposed here, would give equal exposure per asset. Memories would need to join the same cycle, and the cycle would need to update when the day's memories change. A lighter alternative could be a weighting mode proportional to asset count (e.g. asset_weighting: linear).

[damongolding]

@guillaumemichel

Thanks for the detailed numbers. I added asset_weighting to give a more human expectation of random selection: bigger sources should show more often than small ones, but not strictly in proportion, otherwise a small album (or today's memories) would almost never appear. So I'd rather not move to a fully proportional mode as the default. I do agree that memories show up too often though.

I reran my tests with a no-weighting baseline. Each run is about 100 picks from AlbumA (9109 assets) and AlbumB (20 assets), with 19 memories where enabled.

#	asset_weighting	Memories	memory_weight	AlbumA	AlbumB	Memories
1	off	on	1	41	29	30
2	on	on	1	68	16	17
3	on	on	0.5	69	18	13
4	on	off	-	88	12	-
5	off	off	-	51	49	-

(Run 2 totals 101 picks; the rest total 100.)

• Weighting off splits picks about evenly per source (test 1, test 5). Weighting on shifts picks towards the large album, but small sources still get a much larger share than their asset count alone would give (test 2, test 4).
• Memories (19 assets) behave like AlbumB (20 assets) at memory_weight 1, so each memory is shown far more often than each photo in a large album. This is the part I agree is disproportionate.
• memory_weight is a penalty applied on top of the asset-count weighting and only affects memories. At 0.5 memories dropped from 17 to 13 picks, but at around 100 picks per run that's within noise.

I do mean to look (at some point) at how memories are weighted so that their share is more sensible.