87 Commits

Include renames

Author	SHA1	Message	Date
peter	8a50538275	fix(ui): a write that fails says what failed and why, wherever it fails ... `req` opens its blocking dialog for 400/409/422/5xx only. A 403/404/429 was left to the caller and a 502-504 or lost connection got just the self-clearing connection notice, so 34 mutations without a reporting onError and 15 direct api writes with a bare or missing catch failed in silence: a hidden channel that snapped back, a share link that never revoked, a confirmed account delete that ended with nothing said. - lib/queryClient: one MutationCache reporter. react-query awaits it BEFORE the mutation's own onError, so it waits a task and skips a failure the site already reported; the toast title comes from `meta.failTitle`, `meta.errorShownInline` opts out. - notifyActionError: title names WHAT failed, the line under it says WHY (`failureReason`: a structured localized detail, else the status). It marks the error reported (`markReported`), so nothing reports one failure twice; `notifyKnownFailure` for a site's own specific sentence. - Every silent site named (45 new HU/EN titles, 4 reasons). Stale "the global dialog shows it" comments corrected on the job actions, channel block, Plex sync, cookies, download enqueue, account delete and usePref. - Channels passed the tag hook's channel id to the reporter as the error; the tag and priority hooks now report themselves, with the real error. - A contract test keeps every useMutation naming its failure; CLAUDE.md gains the pattern row. - history.dom.test: the "navigates only once the entries are back" assertion raced an async act's macrotask flush (1 in 5 runs); it now asserts from a later popstate listener.	2026-09-13 01:45:28 +02:00
peter	a0114deff1	fix(api,ui): a refused write says why, wherever the refusal happens ... Round 5 taught `notifyActionError` to discard a plain-string `detail` in favour of the caller's translated fallback, because `req` leaves 403/404/429 to the caller and those routes hand-write English. Three places did not get the message. **The demo account lost its explanation.** `require_human` refused with a plain string, so from that commit on the shared demo account got its caller's generic "couldn't do that" and no hint that the demo account was the reason — and the gate is not backed by a UI gate everywhere: the comfort shelf has no `is_demo` check, so the pin button is live and simply fails. A structured `{code: "demo"}` and an `errors.demo` string in both locales. The two auth routes that hand-roll the same check were swept with it. **`ChatThread` carried a second copy of the contract.** It filtered 404/429 itself and then did `e.detail || t(…)`, the pre-fix order, so the central fix could not reach it and "That member hasn't set up messaging yet." stayed English under a Hungarian UI. It goes through the shared helper now, and a contract test pins the remaining raw-`detail` consumers as an explicit SET — never a count — so a new copy fails the gate instead of shipping. The five on that list are inline surfaces (a form field's error line, a setup banner) and are deferred with the ~60 backend routes whose details they print. **The Plex "Add to playlist" dialog was still silent.** Same shape as the collection editor round 5 fixed and the YouTube twin that already had the fix: no catch, so a playlist deleted on another device answered a structured 404 that nothing reported — the tick never flipped, the gone row stayed, and the floating promise became an unhandled rejection. Also: the `ABORTED` sentinel's VALUE was asserted nowhere. The consumer test hand-built the error it expected, so replacing `xhr.onabort`'s rejection with a friendlier message left the lane green — and every upload the user cancels would then raise a red "the upload failed" toast, which is what the sentinel prevents. Both producer tests assert through `isAborted` now. And two backend tests were pinning fewer sites than their own docstrings claimed: the channel-404 loop said "all five" and issued three requests (explore and subscribe unexercised, the excuse for subscribe naming a different call site with a different reason slug), and the recipient/job test named three refusals and requested two — `share_download`'s `not_found("recipient")` had no test in the suite at all, nor did the locale keys added beside it. Every site named now has a request behind it. 6 tests, mutation-checked against 7 mutations: the demo detail at both the gate and an auth route, a re-hand-rolled ChatThread, the silent Plex dialog, the abort sentinel, and each unpinned 404 — all red on the test that names them.	2026-09-12 05:50:31 +02:00
peter	4a7b65d187	fix(api): a refused write is named, in the reader's language ... Deep-review round 5, over round 4's own fixes. - `notifyActionError` preferred the server's `detail` over the caller's translated fallback, and `reportFailure` deliberately leaves 403/404/429 to the caller — so for exactly those statuses the dozen call sites round 4 converted started printing whatever English a route hand-wrote into an otherwise Hungarian UI ("No user with that email.", "Not subscribed to this channel", "Unknown job"). A STRUCTURED detail is still preferred: `req` has already run it through `localizeDetail`, so it is both localized and more specific. A plain string is not. - The other half of the same defect, on the backend: round 4's `get_or_404(what="channel")` sweep reached exactly ONE of the five identical sites in channels.py and shipped the HU/EN string with it, so the Block button said it in Hungarian and the four controls beside it in English. All five are converted, and the subscription / share-recipient / scheduler-job 404s with them (two new reasons in both locales). - `PlexCollectionEditor`'s add/remove, take-over and delete were try/finally with no catch — in the very file round 4 edited to give `createNew` one. 403 and 404 are the caller's to report, so the tick simply never appeared and a CONFIRMED "delete collection" did nothing, silently. - `UploadDialog` is the only `uploadReq` caller and kept an empty catch whose comment still claimed the global error modal had it. It had not since `reportFailure` became shared: a proxy 502 raised only the self-clearing connection notice and a 413/403/404 nothing at all, so the dialog snapped back to its pre-upload state with no error named. The user's own Cancel stays silent — and since a cancel and a network drop both carry status 0, that difference is now a named `isAborted` rather than a string literal at each end. Regression tests for each (5 vitest, 2 pytest, plus two existing assertions corrected), all mutation-checked: 6 mutations, each red on the assertion it is named after. vitest 1007, pytest 1127.	2026-09-12 04:07:25 +02:00
peter	6d49da17fe	fix(api): a write that hit a connection failure is still reported, and every failure is reported once ... Deep-review round 4, the "one report per failure" contract round 3 introduced. - `req` marked gateway (502/503/504) and network failures "already reported" because they raise the connection notice. But that notice is about connectivity and removes itself on the very next answer — which every caller's own resync refetch fetches at once — so a delete that hit a keepalive reset flashed the notice and was then reported nowhere, the list still there. Only the durable reports (the error dialog, the 401 sign-out) count now; the caller says the action failed. - A connection notice the user closed swallowed every later one for the rest of the visit; it is raised again. - `req` and `uploadReq` share one failure policy (`reportFailure`). The upload copy had drifted: a 502 opened the blocking "Server error (502)" dialog and cleared a notice that was still true. - A taken Plex collection name is a structured 409, localized, and the create/rename calls are quiet: it was an English dialog plus a Hungarian toast. `notifyCollectionEditError` is gone. - The mutation onErrors that toasted unconditionally after a non-quiet request (invite approve / deny / add, demo whitelist, audit clear, scheduler, share, full history, edit, config tests, tag attach) go through `notifyActionError`; the playlist delete's hand-rolled copy of it too (it takes a level now). The user role / suspend / delete actions had no onError at all: a user deleted in another tab failed silently and stayed listed — now said, and the list refetched.	2026-09-11 23:27:48 +02:00
peter	1cfe6a7f59	fix(api): a gone row and a refused playlist action are said in the reader's language, and a failure is reported once ... Deep-review round 3 of bug hunt 2026-09. - get_or_404 / owned_or_404 answer a structured {code: "not_found", reason: <what>} (errors.notFound.* in HU+EN, generic fallback). The structured-404 fix of round 2 had gone into the ad-hoc `_own_playlist` (CLAUDE.md's "Not" pattern) while the shared helpers stayed string-only, so views, tags, pins, Plex playlists, invites and users still 404'd in English. `_own_playlist` now goes through owned_or_404; admin's hand-rolled user lookups use get_or_404. - A move into a list that is gone names the TARGET (reason "move_target") — "this playlist doesn't exist any more" was read as the list on screen, which still exists. - Every refusal in the playlists router is a {code: "playlist", reason} (playlists.errors.* HU+EN) instead of a bare English string shown verbatim in the Hungarian UI. - `req` / `uploadReq` mark the errors they already put on screen (the error dialog, the connection notice, the 401 sign-out), and notifyActionError skips those. The watched toggles, the saved views and a playlist delete toasted a fault the dialog was already showing; Playlists' two hand-written status filters now go through the same check.	2026-09-11 18:05:19 +02:00
peter	4f37c41021	fix(plex): a subtitle failure about one position no longer ends the track, and windows are read ahead and never wait behind a full pass ... Deep-review round 3 of bug hunt 2026-09. - `failed` is now final only for a track that can never be text (bitmap, no item/track/file). A Plex hiccup or a stretch ffmpeg could not read answers `unavailable`: said, polled again every 5 s, and the <track> stays mounted when cues exist elsewhere (gen > 0). Re-picking the selected track asks the server again at once. - Within LOOKAHEAD_S of a covered stretch's end the next window is read ahead, instead of only once the playhead has fallen off it (subtitles dropped out at every edge while the full pass was backed off or slower than a window lasts). - Windows and full passes run on separate pools with separate in-flight caps, so a window never queues behind (or is refused by) minute-long full passes — the pool comment promised that and nothing enforced it. - A pass that times out is TERMinated and keeps what it reached (published as partial) instead of being killed and discarded. - Lapsed failure memos are swept on every write (they were only pruned when the same key was read again, so polling fresh keys grew the process without bound). - `publish` no longer merges into a sidecar with no VTT behind it, or claims a region whose VTT write failed, or overwrites an unreadable track with one window. - A NUL in a rating_key names no row (it was a DataError, a 500, on every Plex route) and no longer 500s the status poll. Tests: 16 new, each mutation-checked (18 mutations, all red on the test that names them).	2026-09-11 18:04:30 +02:00
peter	dcd8a9566a	fix(playlists): the player's Remove follows the list it was launched from, the player survives a change of selection, and a gone list is said in the reader's language ... - D3 snapshotted the removal's TARGET, but whether the player offered Remove still followed the selected list: launched from Watch later (no Remove, by design), selecting another list under it made Remove appear — and delete from Watch later. The snapshot now carries the launch list's editability too. - Selecting another list under an open player (the command palette works over it) put the page into "Loading…", and the player was rendered only in the loaded branch — it vanished mid-playback and came back at its launch video. It now sits at one place in the tree whatever the page is doing. - A removal takes the video out of the CACHED list as well as the rows: the player's progress checkpoint rewrote that entry before the refetch landed, handing the membership guard a list that still held the video — the row came back and the undo history went. - The watched-state callback refreshed the selected list, not the launch list (D3's sibling). - `_own_playlist`'s 404 is structured (`{"code": "playlist", "reason": "not_found"}`) and localised: the bare "Unknown playlist" reached the Hungarian UI in English, which also made round 1's new `removeFailed` string unreachable. Both Remove and Move report through `notifyActionError` now. - The "viewer moved on under the confirm" test stepped back only once, which lands on the same video whether or not the removed one left the queue; it now takes the second step that tells them apart.	2026-09-11 03:19:07 +02:00
peter	d2ba65e383	fix(plex): the subtitle poll backs off on errors, a failed <track> is replaced, and a resume asks for the right window ... Deep-review R2, plus one defect found while verifying it on localdev. - The status poll re-armed every second after a FAILED request: `data` stays empty on an error, so it read as "still preparing" for as long as the player was open — and the request was not quiet, so a persistent 500 re-opened the global error dialog every second. It now backs off to 10 s (a blip still heals on its own) and is quiet; the player already shows the failure inline. - A <track> whose own VTT fetch failed never fetched again: with the server's answer unchanged its key was unchanged, so React kept the dead element — silently blank subtitles. The key (now built in the hook, where it is tested) carries a failed-load count; after two remounts the track is reported as unavailable instead. - Found in UAT: until the first timeupdate `abs` is 0, so after a resume every poll said at=0 and the first window was cut around the head of the film (a resume at 20:00 polled at=0 for as long as it stayed paused). The poll reports the session's start until playback ticks. And the window's dedup identity is the track plus a window-length bucket of its start — keyed on the track alone (R1), the right window queued behind that wrong one. The poll's start/stop rules finally have tests (every earlier one resolved a single fixed answer). Verified on localdev against Westworld S1E6 resumed at 20:00: the polls carried at=1197, one subtitle line on screen at 21:02, the poll stopped at `ready`; the real file's window (56 cues) + full pass (608) merged to 608 — the old merge would have served 664. 11 mutations, all red.	2026-09-11 01:08:27 +02:00
peter	cf7ec5e9ec	fix(plex): the subtitle extractor's seams — doubled cues, a truncated track cached as whole, a poll that respawned ffmpeg ... Deep-review of the bug-hunt round (R1). The background extractor from ed4ab4e1 held, but its seams did not: - Window + full pass doubled every cue in the first hour. merge_vtt de-duplicated on the raw timing text, and the two passes spell a timestamp differently (shift_vtt writes HH:MM:SS.mmm, ffmpeg's webvtt muxer drops the hour below 1 h; shift_vtt(-0.0) never normalised the full pass). Timing is now parsed and re-emitted canonically, keyed with the cue text so two cues sharing a time survive. - A full pass that exited non-zero was published as complete: "ready" forever, subtitles ending where ffmpeg died, and no eviction to ever retry. It now covers only up to its last cue, is never complete, and records the failure memo. - The window's dedup identity held the live playhead, so every 1 s poll queued another read of the file. It is keyed on the track now, and a queued job re-checks coverage before reading anything. - A sidecar track waited behind an unrelated embedded full pass (the full job is per item). Its window job now fetches it whole — one small request. - The <track> fetch ran the scheduler at position 0: an unrequested window over the head of the file, and a refusal of a window that was on disk. It is a pure read of the cache now. - publish() is serialised (a lost update became permanent once complete was set); the pool is shut down and running ffmpeg children killed at app shutdown (they held interpreter exit for minutes); ?at=inf is a 422, not a 500; and both subtitle routes use current_user instead of the cookie-only poster gate, which let a suspended or epoch-revoked session keep scheduling reads (pre-existing). _extract_and_publish finally has tests of its own — every earlier test stubbed it out. 19 mutations, each red on the assertion that names it.	2026-09-11 00:52:59 +02:00
peter	889d2acf52	feat(plex): the collection page sorts, and a linked collection has a name ... Two halves of the same report ("Collectionben nem működik a rendezés?"). The pasted browse URL sorts correctly — that part was working. What did not: The Collection INFO page had no sort control at all and a hardcoded release-year-ascending order. It now shows the browse grid's Sort control, with the browse grid's vocabulary, because a second sort vocabulary on a neighbouring surface is exactly the kind of drift this repo keeps paying for: `PLEX_SORT_KEYS` is now one tuple in `plex/query.py`, and a test pins BOTH implementations to it — browse's key→column map (extracted from the handler to be reachable) and the collection page's key→member map. A key added to the vocabulary without teaching one of them fails the gate instead of putting a dead option in the menu. Ordering a collection cannot be a single ORDER BY: its two legs are different tables, so the merged member list is sorted in Python. Members with no value for the key sink to the END in both directions (a movie with no rating is not "the worst rated" — the browse grid's `nullslast()`), and ties always resolve title-ascending, so flipping the direction reverses the ranking rather than the alphabet inside it. `lastwatched` needed the show leg's `resumed_at`, so the page now takes ONE rollup pass that yields both the badge status and the recency instead of the status alone — without it that menu entry would have ordered every show as never-watched. The default stays release-year ascending: a franchise reads in release order, and that is what the page did before. The other half: a shared Plex link carries the collection filter as bare rating_keys, so a link opened cold had no name for them — the sidebar token rendered `17045` and the chip could only say "Collection". `GET /api/plex/collections` takes a `keys=` CSV now, and a display-only hook resolves just the missing ids. It deliberately does NOT write them into `collectionTitles`: that map is hashed into the Plex query keys, so storing a resolved label there would split the cache from the identical state and refetch the grid for a piece of text. Verified in the browser on localdev against the real Plex library: the movie collection's menu offers Length and the show collection's does not (the same scope rule as browse); rating-ascending reorders 8.1/7.4/7.2/6.6/6.5 correctly; `lastwatched` on a show collection brings the in-progress shows up; the choice survives a reload (it is a server pref, on its own key so opening a collection never re-sorts the library behind it); and the reported URL now reads "Pirates of the Caribbean Collection" in both the sidebar and the chip. 12 pytest + 8 vitest, mutation-checked against 14 mutations (direction ignored, nulls first, no stable tiebreak, unknown key untouched, wrong default, show recency dropped, empty `keys=` falling through to everything, a key missing from either sort map, every id refetched, ids unsorted, fetched titles unmerged, the chip ignoring them, the hook's result never reaching the builder) — each red on exactly the test that names it.	2026-09-10 22:05:39 +02:00
peter	ed4ab4e13c	fix(plex): subtitles stop blocking the request, and stop re-reading the file ... Bug hunt 2026-09, items 8 and 12 — the two things the Plex player was measurably lying about. Item 8: picking a subtitle track showed nothing for a long time, and the reported workaround was to stop/start until it suddenly worked. Measured on prod against a 17.06 GB MKV with two embedded SubRip tracks: full pass, one track 154 s full pass, both tracks in ONE run 111 s -c:s copy (no WebVTT conversion) 143 s from 1:00:00 to the end of file 66 s a 630 s window at 1:00:00, both 8 s So the conversion was never the cost: ffmpeg streams every byte of the container between its seek point and its stop point, and the array delivers ~140 MB/s. The only lever is reading less. Three changes follow from that: * a window around the playhead is extracted and published FIRST (seconds), and the full pass completes behind it; * every embedded text track rides that same single read — picking Hungarian used to cost a full pass and then switching to English cost another one; * none of it happens inside a request any more. The endpoint answers 202 while a background worker extracts, the player polls /status (carrying its position, so the window follows the viewer), and one ffmpeg run finally has a timeout. -copyts is deliberately absent from a windowed pass: with it ffmpeg ignores -t and reads the whole container anyway (measured — a [0, 600 s] window still took the full 145 s), so a window comes back on a zero-based clock and is shifted to absolute time here. Cached tracks written by older builds have no coverage sidecar and count as complete, so nothing is re-extracted after the upgrade. The <track> is no longer mounted before the server has something to put in it; a "Preparing subtitles: …" notice stands in, and a track that can never be shown says why instead of leaving the viewer to conclude the picker does nothing. Item 12: "Bitrate" read a constant 211 kbps on every remux, because it was the master playlist's BANDWIDTH — which ffmpeg derives from the one stream whose rate it knows, the -b:a 192k AAC track, plus 10%. It is a measurement now: bytes per second of MEDIA from hls.js FRAG_LOADED, accumulated per fragment type and summed (a multi-audio session's video and audio renditions cover the same media seconds, so pooling them would report half the truth), and an honest dash until the first fragment lands. The panel also finally names the audio and subtitle track in play. Verified in the browser against the real Plex library, and every new test mutation-checked.	2026-09-10 19:31:05 +02:00
peter	1630a3df3c	fix(player): the YT progress checkpoint reaches the cache, so a reopen cannot rewind it ... The player checkpointed every 5s and the server stored it, but nothing wrote the new position back into react-query: the close path only marked qk.feed() stale with refetchType "none", and nothing refetches the feed until it remounts (staleTime 30s, refetchOnWindowFocus off). So the resume read the position the cache had been FETCHED with, and the next checkpoint then persisted that older value over the newer one. Measured on localdev: played to 830s, closed (server had 830), reopened the same card without a reload -> the row was back to 751s. 79 seconds of progress destroyed by a reopen, and the card's progress bar never moved either. The Plex player already solved this for its detail query, with a comment describing the identical failure; this is the feed-side twin that was missed in that sweep. patchCachedProgress writes the position the SERVER stored (the endpoint clears trivially-early and near-finished checkpoints to 0, so mirroring our own reading would disagree with the row) into every cached feed page and playlist detail, keeping array identity where nothing changed. A session map covers the second half: the launch queue is frozen at mount, so stepping next->prev back to an item played earlier in the same session resumed from that snapshot. Verified in the browser: 811 -> close 816 -> reopen 825, and the card now shows Continue/Restart.	2026-09-09 23:55:51 +02:00
peter	82914b56ca	fix(e24): the Home surface's three UAT findings — Back, the reroll, and a show card ... All three were measured before they were touched, and the diagnosis moved twice. **Back from a Plex title played off Home landed on the Plex module's root.** One click pushed three history entries: the page navigation, the sub-view opened by the `jumpTo` hand-off, and — under StrictMode, whose effect body runs twice before `setJumpTo(null)` re-renders — that same sub-view a second time. So the first Back visibly did nothing and the second stranded the user on a Discover page they had never visited. A cross-module hand-off is the CONTINUATION of the navigation that brought you there, not a second navigation, so it now REPLACES the page entry instead of stacking on it (`useHistorySubview.open(view, {replace})`, asked for by the jump target). Replacing is also idempotent, which is what disarms the StrictMode double-run. The intent rides on `PlexJumpTarget` rather than being inferred, because the header typeahead jumps from INSIDE the module, where the entry being replaced would be a sub-view the user really was looking at. **"Mást kérek" cycled nine cards and never left the resume tier.** Measured: twelve presses, nine distinct titles, period nine, every one `tier: "resume"` — the shelf and the surprise tier were unreachable by pressing the button. Two causes multiplied: the tiers were tried in a fixed priority order over a 20-row resume rail, so the button just walked down it; and the client's rolling exclusion window of 8 guaranteed the wrap. The press count now rotates which tier answers first (`start`), so each press offers a different KIND of answer — the user's call, given the choice between that, a wider window, and a surprise-only reroll. The fallthrough is kept, so a press does not come back empty because the tier it led with had nothing. The window is matched to the server's own cap rather than a smaller number of ours. **A half-watched series on Home opened the show page.** A movie already went straight to the player; only shows did not — and the comfort shelf and the hero both resolved a show to its next episode while this rail alone did not, handing back six seasons to choose between. The rail row now carries `next`, and the client already played `next ?? card`, so this is a backend fix. Affording it needed `queries.next_episode` to stop loading every episode of the show into Python to pick one of them (236 rows for Friends, 227 for JAG) — three ordered LIMIT 1 probes instead. The show→episode rule now lives in ONE function (`rails.playable`), which is what the shelf, the hero and the rail all call; two implementations are how they came to disagree. Ten mutations run, all ten red for the right test — including a first pass where the press count reached `api.discoverPick` and stopped there, invisible because every Home test mocks that module. The slice now has its own URL test. Verified in a clean browser tab against the live account: one Back returns to Home, the rotation gives resume/comfort/surprise across nine presses with no repeat, and Westworld opens at S1E1 rather than at its show page.	2026-09-06 05:38:28 +02:00
peter	f3c0b7be23	feat(e24): the Home surface — one question, one answer, both sources ... E24 S2. A new `home` module in layout C+ (the mockup the owner picked): the time-budget chips on top, one large hero that answers them, then the comfort shelf and a cross-source resume rail. Home is the landing — deliberately OVER the remembered last module, since landing on whatever you happened to close the app on is the habit this epic exists to replace; `LS.startOnHome = "0"` opts an account back out (Settings toggle lands in S4). No third card component: each unified card carries the native feed / Plex payload, so the rails render through the existing VideoCard (`cardsSmall`) and PlexPosterCard, and `aspect` decides the tile shape without branching on source. Plex playback hands off to the Plex module via a new `jumpTo` type — the player lives there with its lazy hls.js and its provider tree, and mounting a second one on the landing page to save one hand-off would be the expensive way round. Four defects found by driving it in a real browser against the live account, each now pinned by a mutation-checked test: - **The reroll gave the same card back.** A new seed only re-draws the SURPRISE tier; the resume tier deterministically returns the most recently progressed thing that fits, so anyone with something half-finished pressed a dead button. `/pick` now takes an `exclude` list of `<source>:<id>` keys and the client keeps a rolling window of 8. Excluding a SHOW also excludes the episode it resolves to — otherwise the same suggestion comes back wearing a hat. - **"Nothing to suggest yet" flashed over a full library** whenever a reroll was in flight: the new query key has no data for a beat. An empty state standing in for a loading one is the dishonesty the house rules name outright. The hero now falls back to the loaded payload while a pick is pending, and only trusts a null once the pick has RESOLVED. - **A budget change replaced the page — chips included — with a spinner**, so the control you just clicked vanished under your cursor. `keepPreviousData`, the same reason the feed uses it. - **The hero printed twice**, once as itself and once as the first resume tile. Two smaller UI calls made from the same session: the budget caption sits NEXT to its chips rather than in SegmentedToggle's justify-between mode, which on an 80rem page throws the answers to the far edge; and the feed takes the YouTube mark its own toolbar already uses, since Home now owns the house icon. Gate green: ruff, ruff format, 3x tsc, eslint, prettier, knip, vitest 780, pytest 989. Verified end to end on localdev against the real account: budget chips re-answer (matched on REMAINING time — a 51-minute video with 2:46 left is a ten-minute answer), the reroll walks three distinct heroes, and a Plex show tile opens its drill-down in the Plex module.	2026-09-06 04:14:14 +02:00
peter	b28be682fe	feat(e10): make "move a video to another list" one atomic request ... The one-step move S2 needs has no honest client-side shape: "add to the target, then remove from the source" leaves the video in BOTH lists whenever the second call fails, and the reverse order loses it entirely. So it is one endpoint in one transaction — POST /api/playlists/{id}/items/{video_id}/move — which re-parents the existing item row (so `added_at` survives), recomputes `dirty` on both sides, and is idempotent when the target already holds the video. Also publishes `updated_at` on the playlist summary, and bumps it explicitly for the edits that only write `playlist_items` (add / remove / reorder / move). UpdatedAtMixin's `onupdate` fires on an UPDATE of the playlist row, so without `_touch` the rail's coming "recently changed" sort would have seen renames and nothing else.	2026-09-05 19:59:41 +02:00
peter	f98b060e2b	feat(admin): an account panel, and a set-password link that needs no email ... Design option C, chosen by the user 2026-09-05. Nothing in the admin UI ever showed an account's GATE STATE: an admin could see a "Pending approval" chip but not whether the address was confirmed, whether SEC-10 had cleared the password, or which Google account was attached — so every support conversation started by guessing. Clicking a row now opens a drawer that says which gate the person is actually stuck behind, with the recovery actions under that readout rather than in the row. The drawer is `Modal placement="drawer"`, not a second dialog: the layer stack, ESC, the focus trap, Back-to-close and the scroll lock are the hard parts, and duplicating them is how two shells drift apart. It slides in, and honours prefers-reduced-motion like the rest. The link itself (SEC-15, SEC-16, and the everyday "no SMTP and someone forgot theirs") reuses the existing token machinery and the SAME `#reset=` entry the mailed link uses, so the signed-out card consumes it with no new flow. It is a distinct token KIND for one reason: a mailed reset arrives in the mailbox, so completing it proves ownership and confirms the address; an admin-issued link proves nothing about the mailbox — the admin hands it over by whatever means they choose — so it must not satisfy the email gate. Claiming otherwise would be the same false attestation SEC-15 is about. Issuing does not revoke the current password: a misclick must not lock anyone out. USING it rewrites the hash and bumps the session epoch, which is what evicts a squatter — SEC-16's actual remedy. Spending either kind burns the siblings of both, so a completed reset cannot leave a live admin link behind. The non-consuming probe learned the new kind too, or every admin link would have opened onto "this link is spent". The audit log records that a link was issued, by whom, for whom — never the link, which is a live credential-setting secret and the last thing that belongs in a long-lived log a human reads. Not gated on account state on purpose: it is useful for a pre-empted address, a revoked password, a Google-only account that wants one, and a plain forgotten password. Narrowing it would only make it refuse exactly when the admin needs it. The shared demo account is the one exception. Verified on localdev, both languages, end to end: issue from the panel -> the signed-in tab shows the honest "reset links open in a signed-out window" banner with the token still in the address bar -> signing out draws the "Set a new password" form, which is only possible because the probe recognises the new kind. Gate: pytest 925 -> 942, vitest 676.	2026-09-05 01:46:58 +02:00
peter	0cc450d1c9	fix(downloads,sync): bound what one user can make the server fetch, download and spend ... SEC-12: the download box accepts an arbitrary http(s) URL and yt-dlp fetches it from the WORKER, so any approved user could aim the server at the compose network, the LAN or a cloud metadata endpoint — and read the result off job.error, where "connection refused" vs "HTTP Error 401" vs "timed out" is a port scanner. downloads/urlguard.py refuses a URL whose host resolves to a loopback/private/link-local/reserved address, at enqueue AND again in the worker (DNS can move in between, and the worker is where the socket opens). A network-class failure on a `url` job now reports one fixed sentence instead of the raw transport text; the error CODE is still classified from the original, so the localized explanation is unchanged. DNS rebinding is explicitly NOT closed — that needs the connection gated inside yt-dlp — and the module says so rather than implying more than it does. SEC-13: `noplaylist` only demotes a video-inside-a-playlist URL to that video, so a URL that is purely a playlist or channel still expanded into every entry — one enqueue, unbounded downloads. `playlist_items` pins it to one. Size was unbounded too: `check_enqueue` compares the CURRENT footprint against the cap, and a download's size is unknown until it lands, so one job could overshoot by any amount; the owner's remaining budget is now handed to yt-dlp as `max_filesize`, applied AFTER the adapter merge so no source adapter can raise a limit the quota layer set. A join's cut-list is capped at 100: an accurate join emits two filters per segment into one ffmpeg filter_complex. SEC-14: the YouTube budget is instance-wide, so one user holding down a manual sync spent the day for everyone. Per-user (not per-IP — the cost belongs to the account) 3-per-10-minutes limiters on the two bulk pulls, subscriptions and playlists, with separate budgets so one does not close the other. The review also listed /rss, /backfill and /enrich; E3 deleted them, and search stays unlimited on purpose — it is interactive, not a bulk pull. Gate: pytest 896 -> 924 (none skipped), vitest 671.	2026-09-05 01:03:24 +02:00
peter	10c0ca4cf7	feat(email): write to people in their own language (E9.5 S7) ... Twelve mails carried hardcoded English while the app itself has enforced HU/EN parity since E5. A mail is the one user-facing surface nobody can re-render by switching the UI language: it arrives once, in whatever language we picked, and stays that way. That made the epic's own headline mail — "one mail, one click" — English for a Hungarian reader. The text moved to a catalog (`mailtext.py`) with a `text(key, lang, **vars)` renderer, and the parity rule is now a test rather than a habit: every key must carry both languages AND the same `{placeholders}`. A translation that drops `{link}` sends a mail with no link in it; one that invents a placeholder raises inside a background task nobody is watching. Both are silent in production. Every `send_*` takes the language as its second argument, resolved by the REQUEST handler and never inside the mail — these all run as background tasks, after the request's session is gone, which is the same reason the approval mail computes its link in the handler. Where the language comes from, in order: the account's own preference; failing that, the language the person asked us in; failing that, English. The middle one is new — `invites.lang`, migration `0082` — because the mails an access request produces go to an address that usually has no account yet, and the signal does exist: the page their form was submitted from, or the locale Google reported for a sign-in we refused. Captured rather than derived, for the third time in this epic (`google_email` in S3, `preferences.language` in S6 taught the same lesson): a signal that exists only in one moment cannot be backfilled later. So the admin is asked in exactly one place — the invitation to an address they typed in themselves, where nobody has ever told us anything. That send is now a dialog rather than a bare click, which is also where the "you already wrote to them" warning belongs — it used to live only in a tooltip the admin may never hover, guarding the one action whose failure mode is mailing a real person twice. S6's registration `lang` field turned out to be dead on arrival: the backend accepted it, the frontend never sent it, so every account has been storing nothing. The request builders now stamp the UI language themselves — a signal that has to be passed in by every caller is one every caller can forget, which is exactly how it shipped unset. Admins are notified one mail per language group instead of one blast to everyone. They are people with their own UI language; a single message would have to pick one of them and be wrong for the rest. Also removes a duplicated `invited_at` column declaration on `Invite` (two identical definitions landed in S6).	2026-09-04 20:29:33 +02:00
peter	a76bab9b34	feat(auth): one mail, one click — the approval mail carries the confirmation link (E9.5 S6) ... The funnel's common ordering made a person open TWO messages: one saying their access was approved, another asking them to confirm their address. The approval mail now branches on what they actually still have to do — carry the confirmation link, point at sign-in, or say a confirmation mail follows once they register — so the usual case is one mail and one click. A mail that guesses wrong is worse than a plain one: telling someone to sign in while their address is unconfirmed contradicts the screen that will refuse them. That embedded link lives 7 days rather than the usual 24 hours. Nobody sits waiting for an approval — it can easily be read on Monday after a weekend, and an expired link spends the one-mail promise and puts them back on two. The risk is small: the token only ever confirms an address; it signs nobody in and sets no password. The most likely root cause of the 2026-09-03 report that a confirmation mail "never arrived" is here too, and it was never a delivery failure: re-registering an address that already had an unconfirmed account returned in SILENCE — same cheerful "check your inbox", no mail sent at all. It now re-sends the link. Nothing new leaks: the response and its timing are unchanged, and the public verify/resend already does exactly this for the same input. Whitelisting stays silent, and that is a decision, not an omission. The operator opens a door as a possibility — usually already agreed with the person — and a row can sit approved for weeks with nobody registering; a mail fired automatically there would be nudging someone who never asked. Telling them is its own act on its own button, `invited_at` records it so a second click is a decision rather than an accident, and the button only appears where nobody is behind the address yet: "the door is open, come in" is meaningless to someone already inside. Two things UAT caught that no test would have. Every fresh registration appeared in BOTH admin lists at once, because the stuck-sign-ups filter keyed on "unconfirmed" — the rule is now "the address may sign in, and this account still can't", which leaves an undecided request with the queue that owns it. And the invitation button was offered on every approved row, half of which are existing users. Also: the confirmation mail finally says what its link's rules are (once, 24 hours) — the reset mail always has, while this one left the reader to discover both by meeting a dead link. The card's "didn't get the email?" moves up under the form, and the three waiting messages name the spam folder, which is where a first message to a fresh recipient sometimes lands. Registration now records the language the sign-up page was in. Nothing reads it yet — the bilingual templates are S7 — but it is the only moment that choice exists anywhere the server can see, and a preference nobody recorded cannot be backfilled later. UAT on localdev: re-registering re-sent the link (one token became two, one account); approval issued a 7-day token and moved the account into the stuck list with only a re-send; whitelisting mailed nobody; the invitation recorded itself and the row then warned that sending again would write twice. Test data removed.	2026-09-04 04:05:28 +02:00
peter	7acdf5d577	feat(admin): surface the sign-ups that are stuck outside, and let an admin finish letting them in (E9.5 S5) ... Approve an address BEFORE the person registers and their sign-up produces no queue row at all — `_decide` only takes a still-pending invite — so the Access-requests screen sat empty, the tab badge read zero, and the only working move was re-typing the address into the whitelist box. Nobody would guess that, and on 2026-09-03 nobody did. This is roadmap UX-25, where two earlier attempts were reverted after review. Both moved AUTHORITY: auto-activating on registration turns a standing whitelist entry into a bearer grant for whoever registers the address first, and reopening the approved invite to `pending` lets an anonymous sign-up REVOKE a standing approval. What was actually missing was visibility, so this changes nothing about what an unauthenticated caller can cause — the admin could already do exactly this by re-entering the address; they just had no way to know they had to. The section lists every account that cannot sign in yet and says WHICH gate is shut, because the two dead ends look the same from the admin's chair: waiting for activation, or waiting on a confirmation mail. Naming the unconfirmed ones is not decoration — on a no-SMTP instance that is the difference between the owner and whoever registered the address first (SEC-15), and an admin about to let someone in should see it. A person the queue above already covers is deliberately NOT listed here; two buttons for one person is worse than one. Activate is gated on `is_allowed` — the same function the sign-in paths consult, in core, so the button that appears and the badge that counts cannot disagree. Without that gate it would manufacture an inconsistent account: password sign-in only checks `is_active` and would let them in, while their Google sign-in would be turned away and silently reopened as a fresh access request. Letting in someone with no approved invite stays the whitelist box's job, which says so out loud. The badge counts activations SEPARATELY from pending invites rather than widening an existing field's meaning, and only counts what genuinely waits on the admin: an unconfirmed account waits on its owner, so it is listed with a re-send but does not nag. The admin-side resend says plainly what happened, including refusing when the instance has no working SMTP — mail is fail-soft everywhere else, and that silence is exactly what left the 0.78.5 sign-ups with nothing to fall back on. `send_verification_link` is now one function with three callers (registration, the public resend, this one), so the link's shape and TTL cannot drift by who triggered it. UAT on localdev, both languages: the UX-25 shape reproduced end to end (approve the address, then register), the badge counting it, Activate letting them in and dropping the badge, the row losing its Activate but keeping the re-send, a fresh token issued by the re-send, and both actions in the audit log. Test data removed.	2026-09-04 03:27:48 +02:00
peter	b1086e05dc	fix(auth): stop drawing a reset form the link can no longer fill (E9.5 S4) ... Reported from UAT: delete an account, then open its password-reset link. The card drew the full "set a new password" form — because a `#reset=` fragment was present, and nothing more — and only after the user had typed a password did the server answer 400. Measured first: no security hole. A user's tokens cascade away with the row, so nothing can be set on a deleted or a re-created account. What was left is a dead end of exactly the kind this epic exists to remove, and it is not rare: a reset link lives one hour, mail is slow or lands in spam, and whoever got two mails clicks the older one. password-reset/check answers whether a link is still usable WITHOUT spending it, so asking can never cost the user their one real attempt — the property the tests pin hardest. It gets its own limiter, because opening a link must not eat the budget for requesting one, and a throttled caller is told "ok", never "dead": this check may only ever save someone a wasted form, so when it cannot answer it degrades to the old behaviour instead of declaring a live link finished. The confirm endpoint stays the authority, and its failure raises the same named screen, since the token can die between the two calls or the probe itself may have failed. A too-short password is deliberately NOT that screen. The length check runs before the token is spent, so a typo costs the link nothing, and the card tells the two 400s apart by `reason` so only one of them takes the form down. Both email-link confirmations (verify, password-reset/confirm) now answer in the {code, reason} shape S4 introduced. They were the last refusals a user meets by simply clicking an old link while still being answered in hardcoded English under a bilingual UI. The seven remaining bare strings in this module (register, request-access, the demo guards, set-password) sit behind client-side validation the UI does first; they are logged as a follow-up rather than swept in silently here. One bug found by the UAT itself, in the new code: the check went out FOUR times per opened link — StrictMode double-invokes effects and the shell remounts the card as the session probe settles. Harmless per request, but against a per-IP limit it would exhaust the budget in two reloads and then silently fall back to drawing the form unchecked: nothing errors, the feature just stops working. Deduped in a module-level map holding the in-flight promise (a ref dies with the remount that causes it); a failed probe drops itself so a blip is never cached as "dead". The test renders the card twice, because with one render the guard would rot undetected. UAT on localdev: the reported scenario end to end (delete the account, open the link) shows the named screen and no form; a live link still opens the form and completes; the CTA lands on the request-a- link form; one probe per opened link. Throwaway accounts removed.	2026-09-04 02:38:01 +02:00
peter	ed91c83dd7	fix(auth): name the state and the address behind a refused sign-in (E9.5 S4) ... "Your account is awaiting admin approval." was true and useless. It never said WHICH mailbox the account was on, and on 2026-09-03 that silence hid a Gmail alias mismatch for a day: a registration as np.temu@gmail.com met a Google claim of nptemu@gmail.com, and every screen in the funnel agreed to say nothing about it. Every refusal password-login can answer with now uses the codebase's structured {code, reason} detail, built in one helper. The three that arrive AFTER the password is proven carry the address on the account plus both gate flags; the two that answer before it (invalid, rate_limited) carry nothing, so a wrong password and an unknown account stay byte-identical. The frontend renders the first three as a named screen in place of the form — there is nothing to retype once the password is correct — with an icon, the two-gate checklist, the address in monospace, and a resend CTA where one helps. Reporting each gate from its own flag is the payoff of S1: approved-but-unverified is a real state now, and a screen that assumed a sequence would send that user off to wait for an admin who has already decided. The Google access-request notice names the address too, and says so when the request was already on file under ANOTHER spelling of the same mailbox — the honest version of "we didn't open a second one", stated only when it applies. It moved from the query string to the fragment: the notice now carries an address, and a query string lands in every reverse-proxy access log. Same reasoning that put the verify/reset tokens there, and the same owner already clears it. urlencode, not an f-string, because URLSearchParams reads a bare + in a fragment as a space and would mangle exactly the +tag addresses this epic exists to protect. upsert_pending_invite returns the row it settled on beside the is-new flag, since the row's stored address is what the notice has to name and what mail will go to. Deviation from the PendingScreen mockup, deliberately: no "Sign out" button and no separate "Not your address?" link. The mockup drew the panel in the app shell; the accepted decision (a) keeps the pending user session-less, so there is no session to end, and the address is named directly above a "Back to sign in" that answers the same question. UAT on localdev, both languages: all three refusals with the typed spelling deliberately differing from the stored one (the panel named the stored one), the resend CTA carrying the typed address into the resend form, and both access-request banners with a +tag address surviving the fragment round trip. Throwaway accounts and the language switch reverted.	2026-09-04 01:56:55 +02:00
peter	a614ee2435	feat(auth): show the Google address beside the one the account registered with (E9.5 S3) ... An account can now hold two true addresses: the one its owner typed, which a Google sign-in no longer overwrites, and the one Google answers with. Only the first was stored, so Settings could say 'Connected' without saying connected AS WHOM -- exactly what someone who registered with a +tag needs to know. users.google_email (migration 0080) records Google's answer at sign-in and at an in-app link. /api/me exposes it ONLY when it differs from the account address, so the comparison lives in one place and the majority, whose two addresses are the same string, see no change at all. Rendered in the account menu as a muted third line under the identity, and in the Settings sign-in row under the existing hint. A short 'Google' label rather than a brand glyph: the app draws one icon set (lucide), and a generic mail icon next to an email address says nothing. It also reads to a screen reader, which an unlabelled logo would not. No backfill is possible -- Google's answer is only known at sign-in -- so accounts linked earlier stay NULL until their owner next signs in with Google.	2026-09-04 01:23:11 +02:00
peter	c134b514c1	fix(auth): confirm an emailed verification link wherever it is opened (E9.5 S2) ... The token was only ever consumed inside Welcome.tsx, which App renders ONLY when there is no session. Opening the emailed link in a browser that already held a Siftlode session posted nothing, the fragment was then stripped, and the user got no signal at all -- the link simply did nothing. Incognito worked, which is why it survived. Confirmation now happens in App, above that branch: signed out the outcome still drives the auth card's banners, signed in it drives a top-of-app bar. The entry URL is snapshotted once at import time (lib/entryUrl) instead of per component, so no future URL writer can strip a token before whoever needs it has read it -- that ordering race is what broke this in the first place. POST /auth/verify now names the address it confirmed, which matters when the browser holds a session for a different account; the same reasoning as password_reset_required already covers the disclosure. Also here, from the 2026-09-02 review tail: the dead GET /auth/verify goes (both senders emit the fragment form, and the last query-token link expired 24h after the 0.78.7 deploy), a spent #verify=/#reset= fragment is cleared while signed in, and the auth-card banners get role=status. The verifyOkReset copy no longer blames admin approval, which E9.5 S1 made false.	2026-09-03 23:45:31 +02:00
peter	243869401a	fix(auth): stop discarding a legitimate password on admin approval (E9.5 S1) ... SEC-10 revoked any password set while an account's email was unverified, on both the Google-adoption and the admin-approval path. On the approval path that was redundant: password_login refuses an unverified account before it ever reads is_active, so approval hands a pre-emptor's password nothing it could use. All the revoke achieved there was destroying the password a legitimate registrant had just chosen -- and since the admin normally decides before the user reads their mail, 'your password was cleared for security' was the DEFAULT experience, not an edge case. The guard stays on the Google-adoption path, where the real owner does attest ownership. password_reset_required and the ok_reset banner stay: accounts stripped on prod before this change have no other way back in. Two existing tests pinned the old rule, so they are rewritten rather than deleted, and the SEC-10 recovery pack now builds the revoked state through the surviving producer.	2026-09-03 23:32:34 +02:00
peter	3ac3d382e7	fix(auth): stop the address-bar mirror eating emailed auth tokens, and unlock revoked accounts ... Two independent bugs made an email+password registration unrecoverable in prod. The verification link did nothing. urlWithParams/clearParams rebuilt the URL as pathname+query and dropped the fragment — but the one-time auth tokens ride the fragment (#verify=/#reset=, SB3), and the providers that mirror nav params (useUrlMirror in FeedFilters/Playlists/Plex/Channels) sit ABOVE the lazily-loaded <App> in main.tsx. Their mount effect replaceState'd the token away before the auth card's chunk had loaded, so the card read an empty hash: the link opened a bare sign-in page, no request, no banner. Both helpers now carry the fragment over. The account was then locked out for good. SEC-10 nulls password_hash when an unverified account is attested (here: admin approval landing before the user could verify — which the bug above made impossible). That is indistinguishable from a Google-only account, and reset eligibility keyed off password_hash alone, so no reset link was ever issued: no password to sign in with, and no way to get one. users.password_revoked_at records the revocation, reset eligibility honours it, and setting a password again (reset-confirm or set-password) clears it. An account that never had a password stays ineligible on purpose — its owner adds one from Settings. /auth/verify now also answers password_reset_required so the card can say why the registered password stopped working, instead of leaving the user at the uniform "Invalid email or password". Telling the holder of a valid verify token leaks nothing: they have already proved they own the mailbox. The 0078 migration backfills the stamp for rows carrying the exact lockout signature (local, non-demo, no password, unverified), so existing victims recover unaided.	2026-09-02 01:28:45 +02:00
peter	8d7aaad9a8	fix: warn before the delete, not after — plus round-2 copy and a11y corrections ... Round 2 on the feature diff (15 → 12): - still_allowed_by_env now rides the invite LIST as well as the delete response, so the confirmation warns while the admin can still change their mind. It mattered most for a DENIED row on an env-allow-listed address: deleting it silently converted a refusal into a grant, and the only warning arrived after the irreversible click. - Both inbox bodies claimed to name "the most recent" dropped message. The throttle records the FIRST of each hour and never updates it, so they now say "one of them", and the not-configured body finally names where to fix it. - settings.invites.emailOff told the admin they "get no notice when someone signs up" — rendered directly above the queue that shows exactly that. Only the email is lost, and it now says so. - The disabled delete buttons put their reason out of reach: `disabled` drops a control from the tab order and suppresses its title. Switched to aria-disabled + preventDefault, the pattern Playlists.tsx already established for the same reason. - deleteInvite is quiet, so the 409 the UI handles with a translated toast no longer also raises the server's English detail as a modal. - After a completed password reset, Back landed on the reset form again with a consumed token — the history change made that state reachable. The token is cleared on success so the reset view stops being the card's root. - The hu deleteHasAccount named a tab that renders under a different label. Tests: a dom test for the Access-requests panel covering both has_account variants and all three delete outcomes, /api/me flag cases, an ADMIN_EMAILS case, and the env-allowlist test now patches the raw setting so the parsing stays under test.	2026-09-01 23:50:29 +02:00
peter	85043013f0	fix: address the feature review — accurate copy, reachable controls, real coverage ... Round 1 on the feature diff found 15; the substantive ones: - The delete control VANISHED on any invite whose address had registered, which is the ordinary sign-up shape (register writes the User and the pending invite together). The guard stays broad — that row is the account's approval gate, and orphaning it strands someone who can then neither sign in nor be approved — but the control is now a disabled button carrying the reason, on both lists, so an admin never sees a row silently missing a button its neighbours have. - Deleting an entry is not always a revoke: is_allowed falls back to the env ALLOWED_EMAILS / ADMIN_EMAILS lists once no row exists, and an ADMIN_EMAILS address is force-promoted on its next Google sign-in. The route now reports still_allowed_by_env and the UI says so instead of claiming access was removed. - "Deny keeps the row so they can't immediately re-ask" was simply false — upsert_pending_invite reopens a denied row. Corrected everywhere it was stated. - The Configuration warning reads me.email_configured, which save() did not invalidate, so it kept warning about fields the admin had just filled in. - The read-only variant was an aria-hidden span explained only by a Tooltip that the hints toggle can switch off; now a disabled button with title + aria-label. - The delete error path threw away the 409's reason (the stale-list case) and left the stale row on screen. - The throttle window was spent even when no notice was written, silencing the next hour on the path whose job is to stop silent drops. - email_enabled() opened a second session and decrypted the SMTP password on every /api/me poll; it now takes the caller's session. - welcomeMode.dom.test.ts never rendered the card, so reverting the history wiring to useState left it green. A render test now drives the real links and fails on that revert (verified). Plus /api/me flag tests, the registration-shaped pending case, the env-allowlist case, and a release note that matches what the code does.	2026-09-01 23:31:49 +02:00
peter	44f626f732	feat(admin): delete a whitelist entry, and stop hiding a broken mail setup ... Three operator gaps, all found the same way — a person could not sign up and the app showed nobody anything. - DELETE /api/admin/invites/{id} with a delete control on both the pending requests and the previously-decided list. Deny keeps the row so the person cannot immediately re-ask; delete forgets the address. Refused with 409 while a User row exists for it, because is_allowed reads that row and removing it would revoke a live user's access with no other sign — the list ships has_account so the UI withholds the button instead of offering one that fails. - Email is fail-soft by design, which had come to mean invisible. _send() now records an email_undelivered notification for every admin when a message is skipped or rejected, naming the message that was lost, throttled to one an hour. /api/me carries email_configured, driving a standing warning on Configuration → Email / SMTP and above the access-request list. - The sign-in card's Create account / Forgot password / Didn't get the email views are history entries (useHistorySubview), so Back returns to the previous view instead of only moving the address bar. Also: the per-test rate-limiter reset sweeps every loaded app.* module rather than a hand-kept list of three — this change added a limiter outside it.	2026-09-01 23:09:25 +02:00
peter	d7e9240e54	merge main (0.78.2) into playback-class before release ... # Conflicts: # backend/app/plex/stream.py	2026-08-30 19:08:08 +02:00
peter	4827aebb7f	feat(plex): HW HDR→SDR tonemap for 10-bit/HDR transcode (OpenCL on the iGPU) ... Upgrade mode-3's 10-bit/HDR branch from "route to software libx264" (BUG 1's behaviour) to a full-GPU pipeline: VAAPI decode → OpenCL tonemap (hable, HDR10/HLG → bt709 SDR nv12) → h264_vaapi. Gen 9.5 (UHD 630) can't tonemap in the VAAPI VPP (tonemap_vaapi fails), so OpenCL is the only HW route — proven on the prod iGPU at ~4.2x realtime, ~1 CPU core. - stream.py: `_select_encode` returns (hw, tonemap); a 10-bit/HDR HW-decodable source picks the tonemap graph when the OpenCL runtime is present, else drops to software. `_opencl_present` gates on a registered ICD. `_venc_opts` / `_hwaccel_in_opts` gain the tonemap variant (named vaapi+opencl devices, `-filter_hw_device ocl`, hwmap→tonemap_opencl→hwmap reverse). `_want_hw` kept as the hw-half wrapper. The runtime HW→SW fallback still backstops a session that emits no segment. - Dockerfile: add the Intel NEO OpenCL runtime (intel-opencl-icd). It was removed from Debian trixie, so it's pulled from bookworm (22.43 still supports Gen 9.5; the .deb runs on the trixie base — verified live). Harmless without /dev/dri. - route + FE: thread `tonemap` through the session response; the stats overlay mode row reads "transcode · GPU · HDR→SDR" for the tonemap path. - tests: tonemap command branch, the (hw, tonemap) selection matrix (auto/on × 8-bit/10-bit × opencl), start_session tonemap wiring, and the fmtMode tag.	2026-08-30 06:02:45 +02:00
peter	840526b1b8	feat(plex): filter the feed by playback class (Direct Play / Direct Stream / Transcode HW/SW) ... Adds a movie-scoped "Playback" filter to the Plex feed so a user can isolate items by how they play — the groundwork for collecting HW-transcodable (or no-transcode) versions. Four classes derived from the stored `playable` + a new `transcode_hw` facet: - Direct Play (direct), Direct Stream (remux) - Transcode · HW — playable=transcode AND the iGPU can hardware-transcode it - Transcode · SW — playable=transcode, software libx264 only The HW/SW split is precise, not codec-only: a 10-bit/HDR HEVC is HW-decodable yet breaks the VAAPI nv12 pipeline (the same case plex/stream special-cases), so it must count as SW. Backend: - New PlexItem columns (migration 0077): transcode_hw, video_bit_depth, media_probed_at. Migration backfills transcode_hw codec-only so the filter works immediately. - `plex.sync.transcode_hw_capable` is the single classifier; the HW-decodable codec set moves to sync as `HW_DECODABLE_CODECS` and plex.stream imports it, so the catalog facet and the runtime encoder choice can't disagree by codec. - Bit-depth backfill (`_probe_media_batch`, wired into sync): probes only HW-decodable transcode items' video Stream for bit-depth + HDR and refines a 10-bit/HDR HEVC to software. Bounded per run, watermarked by media_probed_at. A codec change resets the watermark (stale probe). - Filter + self-excluded facet on a shared `playback_class_expr` CASE (movie-leg only — a show is an aggregate with no single class). transcode_hw threaded onto the feed/detail/card JSON. Frontend: - Multi-select "Playback" Combobox in the sidebar (movie scope, facet-empty drop-out), active chips, 4-way corner-dot badge (green/blue/amber/red) + tooltip, and an info-page playback chip with a codec · bit-depth subtitle. New `bg-info` (blue) token, i18n HU/EN parity. - Fix a regression where the card's playback dot lost its hover tooltip: the full-card reveal overlay swallowed the cursor; the dot now sits above it (z-20). Gate: backend full lane + frontend typecheck/lint/knip/prettier/vitest all green. Browser-UAT'd on localdev (filter narrows to the SW set, facet counts, badge colour + tooltip, info chip).	2026-08-30 04:45:11 +02:00
peter	dc24d353e0	feat(plex): honest transcode cold-start + encoder in stats (E6 S1d) ... Surface the transcode session's runtime facts in the player. The session response's transcode/hw flags now thread through: the stats overlay's mode row reads "transcode · GPU" (VAAPI) or "transcode · CPU" (libx264) — the at-a-glance confirmation of which S1 path engaged — and the initial-load overlay says "Preparing stream…" instead of "Loading…" for a transcode session, since its first segment is genuinely slower than a remux and shouldn't read as a hang. fmtMode (pure, unit-tested) appends the encoder only for a transcode with a known encoder. i18n HU/EN for the new preparing label. Browser-UAT'd on the XviD fixture: mode row reads "transcode · CPU" live (software, no render node here).	2026-08-30 01:30:53 +02:00
peter	f41c81eb56	fix(downloads): media-library UI review fixes (E7) ... Deep-review remediation on the frontend, all findings adversarially verified: - LibraryPlayer picks audio vs video from the canonical media_kind (single source), not a hardcoded container whitelist, so an uploaded audio file with an uncommon/absent container renders in <audio> instead of a broken video box (legacy null media_kind keeps the heuristic). - UploadDialog aborts the in-flight upload when the dialog is closed by X/ESC/backdrop/Back (not only the footer Cancel); drag highlight uses an enter/leave depth counter to stop the flicker; the progress bar gets a stable role=progressbar aria-label with the value on aria-valuenow. - DownloadCenter's Shared tab renders honest loading/error states instead of a blank panel, and the library/shared row-action gating moves to a single tested helper (lib/downloadActions). Tests: downloadActions gating matrix, the uploadReq XHR path (abort/401/422-localize/onerror), and the media_kind-driven audio/video branch. i18n: downloads.upload.uploadProgress (HU + EN).	2026-08-29 21:52:13 +02:00
peter	584e9ced0c	feat(downloads): local-upload UI — drag-drop dialog + progress (E7 S5c) ... UploadDialog (drag-drop + native picker + optional display name) opened from a new Upload button in the queue add-row. Uploads stream through a new XHR helper (uploadReq in api/core) so the dialog shows real 0-100% progress with a cancel — fetch/req can't report upload progress. The upload lands as an already-done job; the S5b file-kind row gates it to download+share. i18n HU/EN; upload cap/empty errors localize via the shared structured-detail path.	2026-08-29 18:53:53 +02:00
peter	b4ad59274b	feat(downloads): gate library row actions by media_kind (E7 S5b) ... Surface the S5a media_kind discriminator in the library UI. A generic uploaded file (media_kind='file') is download+share only — no player and no timeline to trim, so Play/Edit/Edit-details are media-only; it shows a neutral file glyph instead of an (always-empty) thumbnail and no duration chip (container/size still read). The "Shared with me" tab's file row is gated the same way. Re-download is now hidden for edit clips and uploads too (neither has a re-fetchable source — the backend already rejects both with 409), removing a latent click-to-409 on edit rows. FE-only: the serializer already emits media_kind (S5a). Adds media_kind to the DownloadAsset type and "upload" to the job_kind union; DOM tests cover the file-row presentation (glyph, no img, no duration).	2026-08-29 18:38:21 +02:00
peter	a0b725d779	feat(playlists): two-way (3-way) merge YouTube sync + mandatory preview (S7) ... "Sync to YouTube" was a one-directional destructive push (local wins, deletes from YouTube every item not in the local list), so items added on YouTube were lost and a dirty pull was skipped entirely. Replace it with a real 3-way merge: each item is classified against the last-synced baseline as a local-add, a YouTube-add, or a genuine delete, so an add or delete on either side survives. - Persist the ordered baseline id set (new playlists.synced_video_ids, migration 0075); the fingerprint hash alone couldn't drive a merge. NULL baseline (fresh export / pre-S7 link) unions losslessly on the first sync and records one. - Pure merge_plan(baseline, local, youtube) -> add/remove per side + merged order (local order, YouTube-only additions appended). merge_playlist applies the local side directly and the YouTube side through the failure breaker; the baseline only advances on full success so a partial failure re-converges. - plan_merge/push-plan now report what each side gains and loses; the confirm dialog shows the two-way plan before applying (pushPlanMerge, HU+EN). - Tests: 10 new (pure classification incl. delete-vs-stale-copy; DB apply proving a YouTube-add and a Siftlode-add both survive on both sides, a genuine delete propagates without collateral loss, no-baseline never deletes, create path).	2026-08-28 04:20:29 +02:00
peter	bc33b2ed16	feat(downloads): per-user, per-host yt-dlp cookie/auth support (S6) ... Each user stores their own login cookies (Netscape cookies.txt) for an auth-walled download host (Facebook, Instagram, X, TikTok, Reddit) in Settings; a download of an auth-walled link on that host is retried with the acting user's cookie. Two load-bearing security controls, both in downloads.credentials as the single source of truth so enqueue and the worker can't drift: - cache privacy: a cookie-authed download salts its MediaAsset format_sig with the user id, so the authed asset is private and never cache-served to another user. The worker attaches a cookie ONLY when the asset it is downloading into IS that private, salted identity. - host scope (SEC-12): a cookie is resolved only for a URL whose netloc the credential owns (netloc-scoped _host_is); a look-alike/unrelated host gets none. cookies_enc is Fernet-encrypted at rest, only decrypted in-worker into a 0600 file under staging/.auth/ (survives the retry wipe + _produced_file scan) and unlinked in finally. The blob is never returned by a route, logged, audited, or written to a job's error/snapshot. cookiefile is set after the adapter's extra merge so an adapter can't clobber it. Settings UI is write-only (host + set/updated only, never echoed). New download_credentials table + migration 0074; per-user routes; HU+EN i18n. Tests: host-scope, cache-privacy (no cross-user serve), encrypt-at-rest, write-only API, worker attach-gate; FE dom test for the write-only field.	2026-08-28 03:53:04 +02:00
peter	00527d0cf3	feat(channels): leading '＋ Tag' pill + detail-page Unhide affordance (S6) ... Item 6 — the tag add-trigger now LEADS the chip row (a stable left anchor) instead of trailing it, so on the detail page (bounded=false) adding chips grows the row to its right and the '+'/its editor popover no longer drift. Compact icon in the width-bounded manager cell; a labelled '＋ Tag' pill where there's free width (the detail header). Item 7 — surface the per-subscription 'hidden' flag on the detail GET (channel_detail was omitting it) and add an Eye/EyeOff hide/unhide toggle next to Block on the channel page, mirroring the manager. FE ChannelDetail gains 'hidden'; new channel.* i18n keys (HU+EN). Tests: +3 backend (channel_detail surfaces hidden, both states + unsubscribed default). Gate green: backend pytest 471, FE vitest 498.	2026-08-27 04:02:25 +02:00
peter	56a2ecdec3	feat(plex): shareable Plex-browse state in the URL — scope+filters+sort+show (S4) ... Mirror the Plex-browse content state into the address bar so a browse view is bookmarkable/shareable, the Plex analogue of the feed's urlState. Keys are NAMESPACED (pscope/psort/pshow/pf) rather than reusing the feed's bare scope/sort/show: FeedFiltersProvider actively strips its own KEYS from the URL whenever off the feed page, so a shared key would be deleted out from under the Plex page. The namespaced keys are Plex-unique (like ?v=/?pl), so no other provider ever reads or clears them. - New lib/plexUrlState.ts: plexParamUpdates / plexParamsToState / hasPlexParams. The pf filter blob reuses the SAME appendPlexFilters wire serializer (new public plexFiltersToParams + inverse parsePlexFilters, kept next to each other so a new wire key can't be added on one side only). - PlexProvider: URL-seed wins over localStorage at mount; the account-pin rehydrate persists the seed instead of clobbering it (mirrors feed's initialHadUrlFilters); useUrlMirror mirrors/clears the 4 keys, gated on page===plex. q/field stay out of the shareable contract. - NavigationProvider: a page switch now also nulls the 4 plex keys. Tests: 8 new round-trip cases in plexUrlState.dom.test.ts (FE vitest 483→491).	2026-08-27 03:14:54 +02:00
peter	549aae67cc	feat(channels): suggest your own tags for untagged channels from your tagging pattern (E8·S4) ... Learn, per user tag, which auto TOPIC tags are characteristic of the channels you've tagged it, then suggest that tag for still-untagged subscribed channels whose topics cover enough of the profile. Language auto-tags are excluded from the signal — near-universal within a language, they flooded every channel. New GET /api/tags/suggestions (read-only, deterministic) backed by app/sync/tagsuggest.py. Surfaced in the Channel Manager as dashed "ghost" chips in the tags cell — one tap accepts (reuses the attach-tag endpoint), × dismisses for the session — plus a header badge and a bulk "Accept N confident" (the full-profile matches) behind a confirm. No silent writes (D4 = suggest-and-confirm). Also reflow a pre-existing prettier drift in dateFilter.ts from E8·S2.	2026-08-26 02:18:34 +02:00
peter	edcea87ea5	feat(feed): filter by year — per-year count facet + year control (E8·S2) ... Add a Year filter to the feed rail: quick chips for recent years plus a 'More…' popover listing all years with per-year video counts, sortable by year or count. Selecting a year narrows the feed to that whole calendar year (a published_after/before range applied in the api layer) and is mutually exclusive with the Upload-date control. Backend: new /api/feed/years endpoint + feed_years() — one grouped query that honours every filter EXCEPT the publish-date narrowing (dropped), so the year list stays a live drill-down and switching years never zeroes the others. FE keys the list on the date-stripped filters, so picking a year re-queries the feed but not the list. Wires year through FeedFilters, the filterParams/URL (?year) round-trip, the active-filter chip row, and the panel layout. i18n HU+EN. Tests: feed_years count query (date narrowing ignored, other filters honoured); dateFilter year-clearing; urlState year round-trip.	2026-08-25 02:55:12 +02:00
peter	4ee0dab68f	feat(feed,channels): "No tag" filter for untagged channels (E8·S1) ... Filter to channels you haven't personally tagged in the channel manager (no user-owned ChannelTag; auto language/topic tags don't count): - Feed: a "No tag" sentinel in the "Your tags" sidebar combobox (exclusive with real tag picks) + a removable "Untagged" chip; new `untagged` bool feed param / `notag` URL key, persisted + coerced on every filter path. - Channel manager: a virtual "No tag" chip in the tag-chip row filters the table to untagged channels (client-side, shared NO_TAG_SENTINEL). Backend `untagged` is a plain channel-level narrowing, so feed_summary keeps it applied in the base pass — the count/facet lockstep holds with no mirror. Note: item E (per-tag counts) and item D (Any/All toggle) were already shipped; S1 delivers only item B.	2026-08-25 01:44:34 +02:00
peter	6af238c2ea	fix(plex): resolve deep-review findings on the Discover/Collections batch ... Round of USER-triggered deep-review fixes (11 CONFIRMED + 1 PLAUSIBLE, all verified) on the 22-commit branch: - collections: split the mutate-then-resync error surface. A resync READ that fails after a successful Plex mutation no longer reports a false 422 "Plex write failed" + rollback; it returns 502 "sync pending" (the next full sync reconciles the mirror). New _write_or_pending_error helper; delete is exempt (no Plex read). Covered by new happy-path / 422-rollback / 502 tests. - New-collection dup-name guard is now advisory only: existingNames is the search-scoped, all-library union, but the backend enforces uniqueness PER library — so it no longer blocks a valid same-name collection in another library, and the backend 409 is localized to nameTaken. - member-remove now confirms before the write-through (matches delete-collection). - add-title / new-collection library search render an error state on request failure instead of a misleading "No matches". - history: seed navCounter past the current entry's persisted sfScroll on load so post-reload ids can't collide with back-stack entries and mis-restore scroll. - PageScroller: LRU-cap the navId-keyed savedScroll map (was unbounded). - share isIntrinsicReadOnly between the browse tile and the info page so the lock/edit affordance can't drift.	2026-08-23 06:57:33 +02:00
peter	5d99a5f253	feat(plex): Collection info page — hero, play/shuffle, and write-through editing (B) ... Clicking a collection tile now opens a dedicated Collection info page (like the Plex-web one) instead of just applying it as a filter. New GET /collections/{rk} returns the hero aggregates (year range, most-restrictive member cert, total runtime) + the members ordered by release year then title; a new PlexCollectionView renders the hero (art/title/meta/ summary+More) and the member grid, with a Play-all and Shuffle over the playable leaves (reusing the player's existing queue + auto-advance). For a non-external, admin-enabled collection the page offers rename / delete / add-title (a search picker) / remove-item, all through the pre-existing admin endpoints that write THROUGH to Plex (each edit awaits and re-fetches — no optimism, since a Plex write can 422). An eligible collection shows "Enable editing" first (the DB editable flag). Read-only ones (smart / imdb / tmdb / … auto-lists) are marked with a lock on both the info page AND the browse tile, up front. New `{ kind: "collection" }` sub-view wired through plexSubUrl (bookmarkable ?v=collection:rk), PlexBrowse (render branch, Backspace back-nav, tile handler), with a round-trip test. Verified live: tile→page, hero + chronological members (James Bond 1962→2021, PG-13, 55h), Play/Shuffle, Enable editing → edit controls + remove-X, the add search (marks already-in titles "Added"), and the read-only lock on external collections. Real Plex mutations wired but not executed against the live account. Gate: tsc/lint/knip/prettier clean, 424 vitest; backend ruff clean, 6 collections tests (+ a detail-hero/ordering assertion).	2026-08-23 04:40:09 +02:00
peter	c0d869089d	feat(plex): add a "Recently watched" rail to Discover (D) ... A new Discover rail listing what the user last FULLY watched, newest first: a movie as its own card, a show as the specific EPISODE watched (carrying its show title via leaf_card). Sits above Recently added. Movies honour the sidebar filters like the other rails; episodes carry no filterable metadata so they don't. Clicking a card plays it (the existing onCard path already routes episodes to the player). Bilingual heading added. Verified live: the rail renders watched movies + episodes with Watched badges. Gate: tsc/lint/knip/prettier clean, 423 vitest; backend ruff clean, 13 discover tests (+ a recently-watched movie+episode assertion).	2026-08-23 04:08:28 +02:00
peter	37d11b602f	feat(plex): redesign browse tiles — 2-poster montage top, readable label band ... The full-bleed 4-poster collage drowned the on-tile text. Split PosterTile in two: the top half shows up to 2 montage posters, the bottom half is a solid colour-hash band that carries the label, so the text is always readable. Genre tiles drop the count (just the label now); collection tiles show the name on one truncated line plus a sub-line of item count · total runtime. A group with no art falls back to an all-colour tile. Backend: `/collections` cards gain `total_runtime_s` (a new `runtime_by_key` grouped sum) and their montage art is capped at 2. Frontend: PosterTile reworked; a `collectionMeta` helper builds the count·runtime sub-line via the existing formatRuntime. Verified live: collection and genre tiles render 2 posters over a readable colour band with the right sub-lines; colour fallback intact for art-less groups. Gate: tsc/lint/knip/prettier clean, 423 vitest; backend ruff clean, collections tests green (+ a new art/runtime assertion).	2026-08-23 03:52:21 +02:00
peter	da3cb5e694	feat(plex): poster collages on the genre + collection browse tiles ... The Browse-by-genre tiles and the Collections browse tiles were flat color-hash gradients. Give each a 2×2 collage of its top films' poster art, with the color hash kept as the fallback so a group with no matching art (a show-only or empty collection) never renders blank. Backend: a shared `top_art_keys` windowed query returns, per key (a genre value or a collection rating_key), the top few items' rating_keys — best-rated then newest, in one query. Wired into the Discover genre tiles and the collections union endpoint; the client renders the posters from the existing /api/plex/image/{key} endpoint, so no new image plumbing. Frontend: a shared PosterTile component (collage + scrim + label, color-hash fallback) replaces the two ad-hoc colored-tile implementations. Verified live on localdev: genre tiles and collection tiles render real poster collages, with the color fallback correctly kicking in for groups without art. Gate: tsc/lint/knip/prettier clean, 423 vitest; backend ruff clean, 11 discover tests (incl. a new genre-art assertion).	2026-08-23 03:10:36 +02:00
peter	8f1309fa18	fix(plex): round-2 deep-review follow-ups on the review fixes ... Second review round, scoped to the round-1 fix commit (where round-1's own fixes introduced new code): - The collection chip-remove pruned collectionTitles to an empty {} on last removal, which still hashes differently from the pristine no-collection state (key absent) in the React Query keys → a residual cache split. Collapse an empty map to undefined so the key-shape matches the pristine one. - Replace the tautological "order-independent signature" test (both objects spread from EMPTY_PLEX_FILTERS inherited the same key order, so it proved nothing) with full literals in genuinely different insertion order that would fail an order-sensitive JSON.stringify signature. - Cover the collectionTitles chip-remove prune (usePlexActiveFilters.dom.test.tsx) and the plexSurprise/plexDiscover lang-key split (queryKeys.test.ts) with regression tests. Gate: tsc/lint/knip/prettier clean, 412 vitest.	2026-08-23 01:53:33 +02:00
peter	b7a4eaff8d	fix(plex): resolve deep-review findings on the filter-bar overhaul ... Self-review of the branch diff (feature/plex-filter-bar-overhaul) against main: - Surprise rail query key omitted `lang` while the backend /surprise now filters against the language-specific genre column → a HU/EN switch under an active genre filter left the rail stale. Key it by scope+lang+filters, matching plexDiscover. - Chip-removing a collection left its entry in `collectionTitles` (hashed into the plex query keys), splitting the cache from the pristine no-collection state and growing the titles map unboundedly. Prune the title on remove, like CollectionPicker. - The saved-views default-mirror effect gained `cfg` in its deps (re-memoized on every live filter edit) → a synchronous localStorage write per keystroke. Depend on the module-stable mirror fn instead. - Collections-browse search input had no accessible name (placeholder only). Add aria-label + type="search". - Extract the tile hue-hash + gradient duplicated between PlexDiscover and plexBrowseLists into a shared lib/hueTile so the two surfaces can't drift. - Document migration 0073 downgrade() as lossy and de-dup non-feed rows before recreating the narrow (user_id, name) constraint (verified by the drift test). - Add unit tests for coercePlexFilters (legacy single-collection migration) and plexFiltersSignature (order-independence, title-ignoring). Gate: tsc/lint/knip/prettier clean, 410 vitest; backend ruff + migration drift + saved-views tests green.	2026-08-23 01:39:29 +02:00