mirror of
https://github.com/4gray/iptvnator.git
synced 2026-10-08 17:06:15 -08:00
4grayandClaude Opus 4.7
d67150d38f
Two independent fixes that compound: the dashboard now renders progressively as each rail's data resolves, and the slowest of those rails (Xtream recently-added) no longer scans the entire content table. Per-rail skeletons (template restructure): The old @if (!ready()) gate hid the whole dashboard until ALL FOUR loading flags resolved (playlistsLoaded, globalRecentLoaded, globalFavoritesLoaded, xtreamRecentlyAddedLoaded). The slowest one pinned the entire skeleton up for the full tail latency — visibly seconds of "loading" even when 3 of 4 rails could have rendered immediately. Replace with per-rail conditionals: - Hero: renders the moment globalRecentItems[0] is available; skeleton shows only while data.globalRecentLoading() is true and no item exists. - Each rail: shows real content if its cards are non-empty, its own skeleton if its dedicated loading flag is true, nothing otherwise. - The Xtream recently-added rail's skeleton is gated on having Xtream playlists at all, so M3U-only users never see a skeleton for it. The loading signals were already exposed on DashboardDataService (globalRecentLoading, globalFavoritesLoading, xtreamRecentlyAddedLoading) but went unused because of the monolithic gate. Same skeleton markup is reused per rail; no styling changes. Drop CAST(added AS INTEGER) in getGlobalRecentlyAdded: The query ordered by sql<number>\`CAST(content.added AS INTEGER)\`. SQLite cannot use an index on a column wrapped in a function, so the existing idx_content_type_added index was bypassed and the planner did a full table scan + sort on content (10k–100k+ rows for a typical Xtream catalog) on every dashboard load. Sort by schema.content.added directly. Xtream stores Unix-epoch timestamps as 10-digit numeric strings (anything since 2001-09-09), so lexicographic and numeric sort are equivalent. The (type, added) index now drives the ORDER BY too — full table scan becomes an index range scan + LIMIT 20. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Entire-Checkpoint: 1e3392724bc8