Fix real data loss: two catalog queries were silently truncating at 300 #2

Merged

kyuno merged 2 commits from fix/catalog-data-loss into master

2026-09-15 22:52:10 +02:00

kyuno commented

2026-09-15 22:49:17 +02:00

Owner

Summary

Regression from the previous PR (#1), reported immediately after it merged: "les catalogues sont cassés, toutes les données sont pas la".

Confirmed directly against the real Emby server (read-only requests, no data changed) rather than guessed:

The "Musique" library has 1229 distinct artists - getArtists gained a defensive Limit: 300 in #1, silently dropping 929 of them (75%).
The "Films" library has 421 movies - getLibraryItems already had a Limit: 300 from before #1, silently dropping 121.

Both limits removed. Confirmed empirically that Emby returns everything when Limit is omitted (TotalRecordCount matched Items.length exactly for both cases) - the render-side concern that motivated capping in the first place is already handled by #1's renderTilesInChunks, regardless of list size.

While in there: renderTilesInChunks was scheduling its next chunk via requestAnimationFrame, which browsers pause for a backgrounded/hidden tab - a real risk now that a list can run past a thousand items and take meaningfully longer to finish rendering. Switched to setTimeout(fn, 0), which keeps running (throttled, never paused) in the background.

Test plan

npm run typecheck / npm test / npm run build on both server/ and client/ (122/122 server tests)
The two real counts (421, 1229) and the "no Limit → Emby returns everything" behavior confirmed live against the real server
Not verified: an actual browser render of either list end to end (no Emby login reachable from this sandbox)

🤖 Generated with Claude Code

## Summary Regression from the previous PR (#1), reported immediately after it merged: "les catalogues sont cassés, toutes les données sont pas la". Confirmed directly against the real Emby server (read-only requests, no data changed) rather than guessed: - The "Musique" library has **1229** distinct artists - `getArtists` gained a defensive `Limit: 300` in #1, silently dropping 929 of them (75%). - The "Films" library has **421** movies - `getLibraryItems` already had a `Limit: 300` from before #1, silently dropping 121. Both limits removed. Confirmed empirically that Emby returns everything when `Limit` is omitted (`TotalRecordCount` matched `Items.length` exactly for both cases) - the render-side concern that motivated capping in the first place is already handled by #1's `renderTilesInChunks`, regardless of list size. While in there: `renderTilesInChunks` was scheduling its next chunk via `requestAnimationFrame`, which browsers pause for a backgrounded/hidden tab - a real risk now that a list can run past a thousand items and take meaningfully longer to finish rendering. Switched to `setTimeout(fn, 0)`, which keeps running (throttled, never paused) in the background. ## Test plan - [x] `npm run typecheck` / `npm test` / `npm run build` on both `server/` and `client/` (122/122 server tests) - [x] The two real counts (421, 1229) and the "no `Limit` → Emby returns everything" behavior confirmed live against the real server - [ ] Not verified: an actual browser render of either list end to end (no Emby login reachable from this sandbox) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-15 22:49:18 +02:00

Fix real data loss: two catalog queries were silently truncating at 300

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

05c4611403

Reported right after the previous PR merged: "the catalogs are broken,
not all the data is there". Confirmed directly against the real Emby
server, not guessed - this app's own "Musique" library has 1229
distinct artists and its "Films" library has 421 movies. getArtists
gained a 300-item Limit in that same previous PR (meant defensively,
alongside the render-side fix below); getLibraryItems already had one,
apparently written before this - both were silently dropping the tail
of the list with no error and no visible sign anything was missing,
which is exactly what "some of the data is gone" looks like from the
outside.

Removed both. Confirmed empirically that omitting Limit entirely makes
Emby return everything (TotalRecordCount matched Items.length exactly
for both the 421-item and 1229-item cases, no server-side default cap
kicking in) - there was never a reason for either app-side number
beyond guarding the render path, and that guard already exists
elsewhere: tiles.ts's renderTilesInChunks (the previous PR's fix for
"the front freezes while it loads") inserts any size of list in small
batches regardless of how large it is.

While in there: renderTilesInChunks itself was scheduling its next
chunk with requestAnimationFrame, which browsers deliberately pause for
a backgrounded/hidden tab - completely ordinary to hit in practice
(switching tabs while a 1229-item list is still loading, which now
takes meaningfully longer than the 300-item case this was written and
tested against) and would have stalled the render indefinitely,
presenting as the exact same "data missing" symptom for a different
reason. Switched to setTimeout(fn, 0), which keeps running (only
throttled, never paused) in a background tab.

Verified: full typecheck/test/build on both projects (122/122 server
tests). The two real counts above (421, 1229) and the "no Limit means
Emby returns everything" behavior were both confirmed with live,
read-only requests against the real server - not assumed. Not
verified: an actual browser render of either list end to end (no Emby
login reachable from this sandbox), though the render mechanism itself
was already verified separately in the previous PR and is unchanged
here beyond the scheduling primitive.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

kyuno added 1 commit 2026-09-15 22:51:40 +02:00

Correct docs/comments left stale by the Limit removal

Publier l'image Docker / test (pull_request) Failing after 4s

Details

Publier l'image Docker / publish (pull_request) Has been skipped

Details

40e019cd81