* fix(xtream): render catch-up start times in the panel timezone
The `{Y-m-d:H-M}` segment of an Xtream timeshift URL is read by the panel
with `strtotime()` in ITS timezone (`server_info.timezone`), never the
viewer's. The timezone was learned in memory only, by the store's
`checkPortalStatus()`, so the Favorites / Recent catch-up resolver — which
reads the STORED playlist row — always fell back to the viewer's local
clock and asked the panel for the wrong programme (#1562).
- Normalize the panel's clock once (`resolveXtreamServerTimezone`): an
ICU-resolvable name is kept, otherwise a `UTC±HH:MM` offset is derived
from the `time_now` / `timestamp_now` clock pair, so spellings such as
`UTC+3` no longer silently mean "local time".
- Persist it on the playlist row through `transformPlaylistMeta` (no-op
when unchanged) and project it back from the payload in
`DB_GET_PLAYLIST`, so both catch-up entry points and a restart see it.
- Format with `hourCycle: 'h23'` (server midnight is `00`, never `24`) and
read timestamp-less EPG `start`/`end` strings in the panel's clock.
- Mock: `tzoffset:tzoffset` scenario with an unusable timezone name and a
+03:00 clock pair; Electron e2e covers Live TV, Favorites, a restart into
Global favorites, and the clock-pair derivation at a UTC-3 viewer.
Closes #1562
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): guard the account-info answer by playlist identity and reject rolled-over dates
Review follow-ups (Greptile):
- A source switch while `get_account_info` is in flight no longer hands
playlist A's status or clock to playlist B: the store is patched only
while the asking playlist is still selected, the timezone is persisted
under the asking playlist's id regardless, and a late failure cannot mark
the newly selected playlist unavailable.
- `parseNaiveUtcMs` reads the constructed date back, so out-of-range panel
strings (`2026-13-01 25:00:00`) are rejected instead of silently rolling
over into a real instant.
- Document that a clock-derived fixed offset is a DST-less snapshot, refreshed
by every account-info check and only ever used for non-standard servers.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): drop a panel clock that no longer belongs to the source
Review follow-ups (Codex + Greptile):
- A metadata update or DB_UPDATE_PLAYLIST that points the source at another
server drops the persisted `serverTimezone` (payload-only) until the next
account-info check, so Favorites / Recent cannot keep rendering the OLD
panel's clock; an update that supplies a clock keeps it.
- A late account-info answer is persisted only onto a row that still points
at the panel it came from — an edit that moved the source during the
request keeps the clock the edit flow dropped.
- The PWA data source and the route-session converter carry the persisted
timezone into the store playlist, so a later response without a usable
clock has a previous value to preserve.
- Mirror the catch-up timezone contract into AGENTS.md.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): drop the stale panel clock inside the UPDATE statement
Review follow-up (Codex): the database worker interleaves requests, so a
read-modify-write of the playlist payload could hand a concurrent upsert's
newer payload back to the past. The `serverTimezone` removal on a server
URL change is now one `CASE … json_remove(payload, '$.serverTimezone')`
expression inside the same UPDATE, guarded by `json_valid`; the spec runs
the real statement against Electron's SQLite on the actual `playlists`
table (moved, renamed, clock-less, malformed-payload and NULL-URL rows).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* refactor(xtream): split the server-clock primitives out of the timezone util
Review follow-up (Greptile): `xtream-server-timezone.util.ts` had grown past
the 300-line file guideline. The zone-agnostic wall-clock primitives (stored
forms, Intl parts, naive parsing) now live in `xtream-server-clock.util.ts`;
the timezone util keeps the Xtream policy and re-exports the public helpers,
so every import and the spec are unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): offer the learned panel clock to storage on every check
Review follow-up (Codex): a transient storage failure left the clock in the
store but not on the row, and the next check compared the answer with the
in-memory value and never retried. The resolved timezone is now always
handed to `transformPlaylistMeta`, whose row-level equality check keeps the
common case a read without a write; a failed write is retried by the next
account-info check.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): apply an account-info answer only to the panel it came from
Review follow-up (Codex): an in-place edit keeps the playlist id while
moving the source, so an answer already on the wire for the OLD panel
passed the id-only guard and patched the new panel's status and clock into
the store. One `answersFor(candidate, credentials)` predicate now gates the
store patch, the error path and the persisted-row transform alike.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): never report another panel's status for the selected playlist
Review follow-up (Greptile): callers gate content initialization on the
value `checkPortalStatus()` returns for whatever is selected NOW. When the
answer no longer describes the selected playlist (source switch or in-place
edit during the request), the store's own verdict about the current
selection is returned instead of the old panel's status — on success and on
failure alike.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): persist the panel clock with one conditional UPDATE
Review follow-up (Codex): `transformPlaylistMeta` reads the row and then
upserts it whole, while the Xtream edit dialog saves through
`DB_UPDATE_PLAYLIST` outside `PlaylistsService`'s queue and the database
worker interleaves requests — an edit landing between that read and the
upsert was silently undone.
Persistence now goes through `IXtreamDataSource.rememberServerTimezone`:
- Electron: new `DB_SET_PLAYLIST_SERVER_TIMEZONE` worker op — one UPDATE
that `json_set`s the payload only while the row still points at the
request's connection and does not already carry the value; a malformed
payload is never rewritten (CASE, not AND, so json_extract cannot run
before json_valid). Wired through the worker types, main handler,
preload, bridge interface, both IPC contract tables and
`DatabaseService.setXtreamPlaylistServerTimezone`.
- PWA: `transformPlaylistMeta`, whose read and write share one IndexedDB
readwrite cursor transaction, plus the localStorage copy.
The store no longer injects `PlaylistsService`; it offers the resolved clock
to the data source and keeps only its in-memory guards. Real-SQLite coverage
for the op (fresh / same / moved / NULL / malformed / missing rows),
delegation specs for both data sources, docs updated.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(xtream): keep the stored panel clock across clockless full upserts
Review follow-up (Codex): a `PlaylistsService` mutation that read the row
before `DB_SET_PLAYLIST_SERVER_TIMEZONE` landed and upserted afterwards
replaced the payload with its clockless snapshot. `DB_UPSERT_APP_PLAYLIST(S)`
now carry the STORED clock into a snapshot that has none while the row still
points at the same connection (`playlistConflictUpdate`, nested CASE so the
json_* readers never run on a malformed payload); a snapshot with its own
clock, or one that moves the source, wins as is. Real-SQLite coverage for
kept / moved / own-clock / batch rows.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* refactor(release): split capture-navigation under the max-lines cap
`tools/release/capture-navigation.ts` had grown to 567 counted lines, past
the 400-line rule, which failed `release-tools:lint` and — because the file
was not in the baseline — the max-lines baseline test on master and on
every PR branched from it. The 19 named setup actions are now grouped by
subject over one leaf module of shared page helpers:
- `capture-navigation-helpers.ts`: playlist-id registry, dialog handling,
navigation moves, `settleUi`
- `capture-navigation-setup-actions.ts`: add-playlist dialogs, settings
sections, remote control
- `capture-navigation-portal-actions.ts`: portal catalogs, live lists,
alternative sources (the two identical live-category flows share one
helper)
- `capture-navigation-download-actions.ts`: the download manager shots
- `capture-navigation.ts`: the `runAction` dispatcher, theme switching and
the re-exported API the seeding driver and the capture script import
Actions call their siblings directly instead of recursing through
`runAction`, so no module depends on the dispatcher. The action vocabulary
is unchanged (same 19 names, same waits and timeouts); every file is under
300 lines and the new modules are listed in the `release-tools` lint target.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* refactor(electron): move the panel-clock SQL into its own operations module
Review follow-up (Greptile): the timezone persistence, invalidation,
upsert-preservation and row projection had landed in
`playlist.operations.ts`, a baselined 1,000-line file. They now live in
`playlist-server-timezone.operations.ts` (155 lines) — the three SQL
shapes plus the payload projection — and the playlist operations compose
them; the baselined file shrinks by 107 lines. Behaviour and the
real-SQLite coverage are unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Xtream Codes Mock Server
A lightweight Express server that simulates the Xtream Codes API for local
development and end-to-end testing. Uses @faker-js/faker with deterministic
seeding so every credential pair always produces the same data.
Quick Start
# Start on port 3211
pnpm nx run xtream-mock-server:serve
# Start with file-watch (auto-restart on code changes)
pnpm nx run xtream-mock-server:serve-with-watch
# Start the mock server plus the Electron app
pnpm run serve:marketing-demo
# Start the mock server plus the browser web app
pnpm run serve:marketing-demo:web
Local Performance Mode
The benchmark control plane is opt-in and binds only to an explicit loopback
address. Use a dedicated port; do not reuse the normal E2E server on 3211.
HOST=127.0.0.1 \
PORT=3221 \
IPTVNATOR_XTREAM_MOCK_CONTROL=1 \
IPTVNATOR_XTREAM_MOCK_CONTROL_TOKEN=local-benchmark-token \
pnpm nx run xtream-mock-server:serve
When enabled, every /__control/* request requires the exact
x-iptvnator-performance-token header, including OPTIONS preflight
requests. The server refuses non-loopback binds and an empty token. The control
routes do not exist when the flag is absent or is any value other than 1.
The Nx serve targets preserve an explicit shell PORT; when it is omitted, the
server parser still defaults to 3211.
Prepare the fixed synthetic fixture before starting a capture:
curl -X POST http://127.0.0.1:3221/__control/prepare \
-H 'content-type: application/json' \
-H 'x-iptvnator-performance-token: local-benchmark-token' \
-d '{"scenario":"performance-100k"}'
The response contains only epoch, scenario, seed, counts, bytes, and
catalogSha256. counts.categories is 60/20/20 live/VOD/series (100 total)
and counts.items is 60000/20000/20000 (100,000 total). bytes and the
SHA-256 cover fixed-order UTF-8 JSON containing, in order, the live, VOD, and
series category arrays followed by the live, VOD, and series catalogs. The hash
input contains no credentials or server origin.
Control endpoints:
| Method | Path | Purpose |
|---|---|---|
| POST | /__control/prepare |
Materialize performance-100k and return its safe manifest |
| POST | /__control/reset |
Reset observations or all state |
| POST | /__control/barriers |
Add a one-shot, abort-aware request barrier |
| POST | /__control/barriers/:id/release |
Release a request that reached a barrier |
| POST | /__control/delays |
Add a one-shot delay of 0..5000 ms for control/smoke tests only |
| GET | /__control/state |
Read bounded rules, held IDs, occurrences, lifecycle ledger, and epoch |
Rules match the exact tuple
(epoch, scenario, transport, action, categoryId, occurrence). Occurrences are
counted independently per tuple without occurrence, so parallel category
arrival order cannot change which rule matches. Empty Xtream actions are
recorded as get_account_info; unknown actions are recorded only as unknown.
Numeric category IDs use canonical decimal spelling: signs, whitespace,
leading zeroes, non-decimal notation, and unsafe integers are rejected. The
state never includes the token, credentials, raw URL/query, response payloads,
titles, or catalog arrays.
reset with mode observations clears rules, occurrences, held requests, and
the ledger while preserving the prepared manifest and epoch. Mode all also
clears fixture caches and the prepared manifest, then increments the epoch.
Held clients are settled during either reset. The legacy unauthenticated
POST /reset returns 410 in performance mode so it cannot invalidate fixture
caches without also invalidating the prepared control manifest; use the
token-authenticated control reset instead.
JSON bodies are strict and limited to 16 KiB. A state epoch accepts at most 32 rules; the ledger retains 128 entries, and occurrence state has 512 slots for the complete allowlisted identity domain without eviction or counter restart. Duplicate IDs/matches, past occurrences, arbitrary scenarios/actions/category IDs, unknown fields, and invalid delays are rejected.
Performance mode is local-only: /playlist.m3u and every performance-fixture
stream/timeshift URL return 410 without redirecting or contacting external
media. Barriers and delays are coordination tools, not timing inputs.
Formal benchmark captures must start with zero barrier and delay rules.
Available Scenarios (credential pairs)
| Username | Password | Scenario | Live cats | VOD cats | Series cats | Items/cat | Status |
|---|---|---|---|---|---|---|---|
user1 |
pass1 |
default | 8 | 8 | 8 | 40 | active |
large |
large |
large catalog | 20 | 20 | 20 | 200 | active |
stress |
stress |
stress catalog | 16 | 16 | 16 | 120 | active |
performance |
performance |
performance-100k | 60 | 20 | 20 | 1,000 | active |
series |
series |
series-heavy | 3 | 4 | 15 | 30 | active |
minimal |
minimal |
minimal (edge cases) | 2 | 2 | 2 | 5 | active |
epg |
epg |
EPG fixture | 2 | 1 | 1 | 3 | active |
tzoffset |
tzoffset |
EPG fixture, UTC+3 clock |
2 | 1 | 1 | 3 | active |
emptyvod |
emptyvod |
empty VOD metadata | 2 | 2 | 2 | 5 | active |
marketing |
marketing |
fictional release demo | 4 | 4 | 4 | curated | active |
marketing2 |
marketing2 |
same catalog, 2nd copy | 4 | 4 | 4 | curated | active |
multisrc1 |
multisrc1 |
multi-source portal A | 1 | 2 | 1 | 5 | active |
multisrc2 |
multisrc2 |
multi-source portal B | 1 | 2 | 1 | 5 | active |
expired |
expired |
expired account | 4 | 4 | 4 | 10 | Expired |
inactive |
inactive |
disabled account | 4 | 4 | 4 | 10 | Disabled |
Any other credential pair is auto-generated using a hash of username:password as the faker seed (6 categories, 30 items each, active account).
multisrc1 and multisrc2 deliberately share one faker seed, so both portals
generate an identical catalog. That overlap is what the VOD multi-source E2E
needs — the same movie present in two different playlists.
API Endpoints
Direct Xtream Protocol
GET /player_api.php?action=<action>&username=<u>&password=<p>[&...]
| Action | Description |
|---|---|
(none) / get_account_info |
User info + server info |
get_live_categories |
Live TV categories |
get_vod_categories |
VOD (movie) categories |
get_series_categories |
Series categories |
get_live_streams |
Live streams (optionally filtered by category_id) |
get_vod_streams |
VOD streams (optionally filtered by category_id) |
get_series |
Series list (optionally filtered by category_id) |
get_vod_info?vod_id=<id> |
Full movie details |
get_series_info?series_id=<id> |
Full series info (seasons + episodes) |
get_short_epg?stream_id=<id>[&limit=N] |
EPG listings for a live channel |
get_simple_data_table?stream_id=<id> |
Full per-channel EPG schedule |
get_simple_date_table?stream_id=<id> |
Legacy typo alias for full per-channel EPG schedule |
PWA CORS Proxy Endpoint
IPTVnator's PWA routes Xtream calls through a backend proxy:
GET /xtream?url=<serverUrl>&action=<action>&username=<u>&password=<p>
Response: { payload: <data>, action: <action> }
Stream URLs (stub redirects)
GET /live/<username>/<password>/<streamId>.m3u8 → HLS test stream
GET /movie/<username>/<password>/<streamId>.<ext> → HLS test stream
GET /series/<username>/<password>/<streamId>.<ext> → HLS test stream
Utility Endpoints
GET /health → { status: "ok", server: "xtream-mock-server", port: 3211 }
POST /reset → clears all in-memory caches; data regenerates on next request
Example Requests
# Account info (direct)
curl "http://localhost:3211/player_api.php?username=user1&password=pass1"
# Live categories (direct)
curl "http://localhost:3211/player_api.php?username=user1&password=pass1&action=get_live_categories"
# VOD details (direct)
curl "http://localhost:3211/player_api.php?username=user1&password=pass1&action=get_vod_info&vod_id=20000"
# Series info (direct)
curl "http://localhost:3211/player_api.php?username=user1&password=pass1&action=get_series_info&series_id=30000"
# EPG for stream (direct)
curl "http://localhost:3211/player_api.php?username=user1&password=pass1&action=get_short_epg&stream_id=10000"
# Full EPG schedule (direct)
curl "http://localhost:3211/player_api.php?username=epg&password=epg&action=get_simple_data_table&stream_id=10000"
# Via PWA proxy
curl "http://localhost:3211/xtream?url=http://localhost:3211&username=user1&password=pass1&action=get_live_categories"
Playwright Integration
The mock server starts automatically with nx e2e web-e2e. Run only Xtream
tests using the @xtream tag:
nx e2e web-e2e --grep "@xtream"
Test files: apps/web-e2e/src/xtream.e2e.ts
Electron Xtream EPG coverage lives in
apps/electron-backend-e2e/src/xtream-epg.e2e.ts.
The Playwright tests use page.route() to redirect the app's backend proxy
calls (localhost:3000/xtream**) to the mock server without modifying any
application code.
Data Characteristics
- Deterministic: Same credentials → same data every time (seeded faker)
- Cached per session: Data generated once on first request, reused until
/reset - EPG: Titles and descriptions are base64-encoded (matches real Xtream API)
- Dedicated EPG fixture:
epg:epgreturns stable live channels plus deterministicget_short_epgandget_simple_data_tablepayloads for timezone-focused tests - Unusable timezone name:
tzoffset:tzoffsetserves the same EPG fixture behind a panel whoseserver_info.timezoneis the ICU-unknown spellingUTC+3, while itstime_now/timestamp_nowclock pair reveals a +03:00 offset — the catch-up URL must be derived from the clock pair (issue #1562) - Release screenshot fixture:
marketing:marketingreturns fictional live, VOD, and series data with local generated artwork underapps/xtream-mock-server/public/marketing - Alternative-source fixture:
marketing2:marketing2returns the identical marketing catalog under a second credential pair, so a movie added from both looks like the same film in two playlists (the premise of the VOD multi-source chip); guide screenshots seed it as a "backup subscription" - Local download media:
marketing:marketingalso serves/movie/...,/series/...and/live/...stream URLs from generated bytes (downloadStreamFixture: 'local-media'; movies finish in under a second, episodes trickle for about 20 s) so release and guide screenshots of the download manager complete without any request leaving the machine. Other scenarios keep redirecting streams to the public HLS stub. - Performance fixture:
performance:performancereturns exactly 100,000 local-only catalog items from index-derived values; it does not use Faker,Date.now(),Math.random(), external artwork, or external media URLs - Timestamp precedence coverage: The
epg:epgscenario intentionally shifts rawstart/endstrings away fromstart_timestamp/stop_timestampso UI tests can prove timestamps drive rendering - Stream IDs: Live 10,000+, VOD 20,000+, Series 30,000+
- Category IDs: Live 101+, VOD 201+, Series 301+
Release Demo Artwork
The marketing:marketing fixture uses 65 original fictional titles for release
screenshots. Its core 30-title artwork pack includes matched posters and
backdrops; 35 additional movie-poster showcase titles use approved local poster
PNGs and the deterministic SVG fallback for missing backdrops. The newest 20
showcase movies are ordered first so they appear immediately in screenshot
catalog grids. Assets are served from:
apps/xtream-mock-server/public/marketing/{poster,backdrop}/
Generate or validate those assets with:
pnpm release:artwork:dry-run
pnpm release:artwork:generate
pnpm release:artwork:validate
release:artwork:generate uses gpt-image-2 through the OpenAI Image API and
requires OPENAI_API_KEY. The screenshot capture workflow only reads committed
local assets; it does not call OpenAI. If a local PNG is missing, the mock
server falls back to its deterministic SVG renderer for development continuity.
The prompt manifest deliberately varies genres and visual media across titles
so the catalog does not collapse into one superhero/poster style.
Architecture
See docs/architecture/xtream-mock-server.md for a full description of the
data pipeline, response shapes, and extension points.