* perf(catalog): fix audiobook detail N+1 + slow people facets Audiobook detail pages were slow in proportion to track count (up to 433 files/book). Root causes, found by EXPLAIN ANALYZE on the live DB: - effectiveAudioSelection ran 3-4 user-store queries (profile, audio pref, library pref) per file inside buildPlaybackInfo's loop, though the results are invariant across a request. Introduce a request-scoped audioPrefResolver that memoizes the store lookups (library prefs keyed by folder); a 400-file audiobook now issues each query once instead of per file. Selection logic is unchanged (audioPreference returns a copy so the original-language sentinel is still resolved per file). - buildAudiobookExtension ran its four independent related-content queries serially; run them concurrently so latency is the slowest, not the sum. - author/narrator browse facets did a full people-table scan; add a (kind, content_id, person_id) index so the facet resolves from an index-only scan of just that kind's credits (~112ms -> ~49ms on the live library). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(catalog): cache audiobook author/narrator group browse The Authors/Narrators audiobook pages were slow on cold load and slow again after a hard refresh (fast only while the React Query client cache was warm). Root cause (EXPLAIN ANALYZE on live, 31K-audiobook library): the grouped browse query is ~234ms/page, there are ~13K distinct authors, and the client pages through the entire list on every load (sequential 500-row requests). With no server-side cache each of the ~20 pages re-ran the full aggregation (COUNT(*) OVER() forces it), so a cold load was ~20x234ms. The client's 60s staleTime was the only thing making a warm revisit fast; a refresh wiped it. Fix: AudiobookGroupsCache caches the full sorted group list per (library, group_by, sort, viewer) for 60s (matching the client staleTime, so no extra staleness) and serves every page as an in-memory slice — one aggregation per window instead of one per page, and a refresh is a cache hit. Also raise the client page size 500->2000 so fewer sequential round-trips are needed now that a larger page is a cheap slice. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(settings): throttle per-request device last_seen upserts Device-setting reads (HandleGetDeviceSetting, HandleGetEffectiveSettings, HandleGetEffectiveSubtitleAppearance) each registered the request's device — an INSERT ... ON CONFLICT upsert of last_seen_at on a single per-device row. A page that fetches many settings fired hundreds of these concurrently; they serialized on that row's lock (observed 100-237ms each, ~250 per page load in the slow query log), taxing every settings fetch. Throttle device registration to one upsert per (profile, device) per 5 minutes via an in-process TTL cache, marking the device seen before the upsert so a concurrent burst collapses to a single write. last_seen_at stays fresh to within the window. Reads no longer issue a contended write on the hot path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf+fix(audiobooks): probe-repair, resume position, cache storm, groups reveal, hot-row + stats index From the full audiobook code review (EXPLAIN + slow-query trace on live): - #1 (P0, detail-page killer): NeedsCriticalProbeRepair required video codec/ resolution/tracks, which audio-only files never have, so PlaybackProbeEnsurer re-ran ffprobe per file on every detail/watch load (up to N serial spawns for an N-track book) and never converged. Gate video-field checks on the file actually having a video stream. TDD. - #3 (P0): abs session-sync rewound the resume cursor — UpdateProgressPosition did an unconditional SET with no monotonic guard, ignored its error, and no-op'd when no row existed (first-listen resume lost). Now a finish-preserving GREATEST upsert; caller logs failures. - #4 (P0 perf): progress reports fired every ~10s invalidated all of catalogKeys.all → refetched every active browse/detail query incl the 13k audiobook group lists. Scope invalidation to the reported item's detail. - #6 (P1 perf): Authors/Narrators page rendered all ~13k groups + cover images at once (main-thread freeze). Incremental reveal: render a capped window, grow on scroll via IntersectionObserver. - #10: throttle abs TouchToken last_seen upsert (one per token per 5min) — same hot-row contention class as the device fix. - #8: index abs_playback_sessions (user_id, profile_id, started_at) for the listening-stats aggregations. Deferred (need contract/validation): listening-time idempotency (client delta-vs- cumulative), scanner deleted-file reconcile, abs session retention job, abs list- handler batch fetch, scanner-output P2s (need re-backfill). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(audiobooks): batch-fetch abs list/shelf handlers (kill N+1) handleSimilarItems, handleItemsInProgress, and handleGetMyProgress called MediaStore.GetAudiobookByID once per row — up to ~500 single fetches (each a few queries) on app open. Add GetAudiobooksByIDs (one access-scoped fetch + people/series hydrated once for the whole set) and look results up from the returned map, preserving order. Underlying primitives (GetByIDsWithAccess, hydratePeople/Series) were already batch-capable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audiobooks): reconcile deleted files on scan + prune session history #5: ScanAudiobookFolder only ever upserted — deleted/renamed books leaked media_items/media_files/memberships forever. Mirror the ebook reconcile: collect seenPaths during the walk, MarkMissing files no longer on disk, then reconcileLibraryMemberships. Safety mirrors ebooks/video: an inaccessible root (unmounted source) is skipped entirely, and a walk that saw zero files while the DB has rows only reconciles after operator cleanup confirmation (ebookEmptyCleanupAllowed) — so a flapping mount can't wipe the catalog. Soft mark only; the existing grace-period purge hard-deletes later. Reconcile runs only on a fully-completed (non-cancelled) scan. (#9 coarse case already handled: audiobookFolderShouldSkip skips unchanged folders; per-file reuse deferred.) #8-retention: abs_playback_sessions grew unbounded (one row per play-start, never deleted) and fed every listening-stats scan. Add an hourly sweep in SessionCleaner: close abandoned open sessions (no /close, stopped syncing >24h) and delete closed sessions older than 90 days. Mirrors the recommendation_cache / missing-files prune pattern. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audiobooks): address max-effort code-review findings From /code-review max on the pre-PR diff: - DATA RACE (P0): SessionCleaner.lastABSSessionPrune is read+written by both the 15s ticker goroutine and the shutdown-path CleanStale call (main.go defers Stop() to after that call). Guard the prune-due gate with a mutex. (CleanStale was stateless before this branch, so concurrent calls were previously safe.) - ScanAudiobookFolder hardcoded fullScan=true into the empty-walk cleanup guard, but it's also called from ScanSubtree (incremental scans). An empty subtree scan would wrongly consume the operator's one-shot empty-cleanup allowance and warn. Thread a real fullScan flag (true from ScanFolder, false from the two subtree call sites), mirroring the ebook path. - Revert UpdateProgressPosition to UPDATE-only (drop the INSERT-on-missing): keep the monotonic GREATEST + finish guard that fixes the resume rewind, but restore the no-op-on-missing contract so a stray sync tick can't resurrect just-cleared progress or create a zero-duration continue-listening row. - Clamp the audiobook-groups handler limit (paging moved into the cache, leaving the old 500/page bound stranded); also gofmt the Scanner struct. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audiobooks): address review feedback for scanner and stats * fix(audiobooks): address review feedback * fix(audiobooks): retry failed session prune --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Quick <31828688+Quick104@users.noreply.github.com>
112 lines
3.3 KiB
TypeScript
112 lines
3.3 KiB
TypeScript
import { useMutation, useQuery, useQueries, useQueryClient } from "@tanstack/react-query";
|
|
import { api } from "@/api/client";
|
|
import type { ProgressListResponse, ProgressEntry, ItemDetail } from "@/api/types";
|
|
import { catalogKeys, progressKeys } from "./keys";
|
|
import { fetchCatalogItemDetail } from "./catalogRead";
|
|
|
|
interface ContinueWatchingOptions {
|
|
enabled?: boolean;
|
|
}
|
|
|
|
export function useProgressList(libraryId?: number, options?: ContinueWatchingOptions) {
|
|
return useQuery({
|
|
queryKey: progressKeys.list("in_progress", libraryId),
|
|
queryFn: () => {
|
|
const searchParams = new URLSearchParams({
|
|
status: "in_progress",
|
|
limit: "20",
|
|
});
|
|
if (libraryId) {
|
|
searchParams.set("library_id", String(libraryId));
|
|
}
|
|
return api<ProgressListResponse>(`/progress?${searchParams.toString()}`);
|
|
},
|
|
enabled: options?.enabled ?? true,
|
|
});
|
|
}
|
|
|
|
export interface ContinueWatchingItem {
|
|
progress: ProgressEntry;
|
|
detail: ItemDetail | undefined;
|
|
isLoading: boolean;
|
|
}
|
|
|
|
export function useContinueWatching(
|
|
libraryId?: number,
|
|
options?: ContinueWatchingOptions,
|
|
): {
|
|
items: ContinueWatchingItem[];
|
|
isLoading: boolean;
|
|
} {
|
|
const enabled = options?.enabled ?? true;
|
|
const { data: progressData, isLoading: progressLoading } = useProgressList(libraryId, {
|
|
enabled,
|
|
});
|
|
|
|
const entries = progressData?.progress ?? [];
|
|
|
|
const detailQueries = useQueries({
|
|
queries: entries.map((entry) => ({
|
|
queryKey: catalogKeys.itemDetail(entry.media_item_id),
|
|
queryFn: () => fetchCatalogItemDetail(entry.media_item_id),
|
|
enabled: enabled && !!entry.media_item_id,
|
|
staleTime: 2 * 60 * 1000,
|
|
})),
|
|
});
|
|
|
|
const items: ContinueWatchingItem[] = entries.map((entry, i) => ({
|
|
progress: entry,
|
|
detail: detailQueries[i]?.data,
|
|
isLoading: detailQueries[i]?.isLoading ?? true,
|
|
}));
|
|
|
|
return {
|
|
items,
|
|
isLoading: enabled && progressLoading,
|
|
};
|
|
}
|
|
|
|
interface ReportMediaProgressVars {
|
|
contentId: string;
|
|
positionSeconds: number;
|
|
durationSeconds: number;
|
|
forceOverwrite?: boolean;
|
|
}
|
|
|
|
export function useReportMediaProgress() {
|
|
const queryClient = useQueryClient();
|
|
return useMutation({
|
|
mutationFn: ({
|
|
contentId,
|
|
positionSeconds,
|
|
durationSeconds,
|
|
forceOverwrite = true,
|
|
}: ReportMediaProgressVars) =>
|
|
api("/sync/progress", {
|
|
method: "POST",
|
|
body: JSON.stringify({
|
|
items: [
|
|
{
|
|
media_item_id: contentId,
|
|
position: positionSeconds,
|
|
duration: durationSeconds,
|
|
force_overwrite: forceOverwrite,
|
|
},
|
|
],
|
|
}),
|
|
}),
|
|
onSuccess: (_data, variables) => {
|
|
// Progress genuinely changed → refresh progress-derived surfaces
|
|
// (continue-watching etc.). Scope the catalog invalidation to THIS item's
|
|
// detail rather than all of `catalog`: a progress report fires every ~10s
|
|
// during playback, and invalidating catalogKeys.all refetched every active
|
|
// browse/detail query — including the large audiobook author/narrator
|
|
// group lists — on every tick.
|
|
queryClient.invalidateQueries({ queryKey: progressKeys.all });
|
|
queryClient.invalidateQueries({
|
|
queryKey: catalogKeys.itemDetail(variables.contentId),
|
|
});
|
|
},
|
|
});
|
|
}
|