4gray Xtream Electron
Read First
docs/architecture/xtream-portal-compatibility.mddocs/architecture/portal-detail-navigation.mddocs/architecture/sqlite-db-worker.mddocs/architecture/vod-multi-source.md
Ownership And Runtime
Routed screens live in libs/portal/xtream/feature; API, cache, Signal Store,
and data sources in libs/portal/xtream/data-access; collection services and
reusable multi-source discovery/resolution in
libs/portal/shared/data-access; reusable views in
libs/portal/shared/ui; pure contracts/helpers only in
libs/portal/shared/util. Screen-session multi-source orchestration stays in
the Xtream feature.
Select ElectronXtreamDataSource only through
RuntimeCapabilitiesService.supportsXtreamSqliteDataSource; otherwise use the
PWA data source. A generic window.electron check is not the capability
contract; existing favorites/recent branches that still use one are migration
debt, not precedent.
Data And Navigation Contracts
- Xtream identity is playlist + normalized content type + provider
xtream_id; collection keys include type and ID. Never resolve colliding live/movie/series IDs by number alone. Distinguish SQLite row IDs from providerxtream_id/stream_id/series_id. - Browse and search use canonical item routes. Favorites/recent use collection-owned inline detail. Preserve enough provider/route identity to recover hidden categories without sending a local database ID to the API.
- Sparse VOD publishes the fallback selection first and recovers its provider category in the background. A playable source is one complete positive stream-ID + extension pair; never combine fields from incomplete candidates.
- VOD multi-source is capability-gated, owner-scoped, Electron-only Xtream-to-Xtream movie behavior. Its reusable core belongs in portal shared data access; the screen session/host belongs in the Xtream feature.
XtreamStore composes portal, content, selection, search, EPG, player,
favorites, recent items, and playback positions.
On the SQLite path, large import/search/delete/restore work remains
worker-backed. Renderer-visible DB progress and cancellation use
operationId. Xtream API requests use requestId, import sessions use
sessionId, and the DB worker also has an internal transport request ID; never
conflate any of them.
Validation
Run both data-source specs plus affected Xtream store/feature tests. Use the closest atomized flow:
web-e2e:e2e-ci--src/xtream.e2e.tselectron-backend-e2e:e2e-ci--src/xtream-responsiveness.e2e.tselectron-backend-e2e:e2e-ci--src/xtream-vod-details.e2e.tselectron-backend-e2e:e2e-ci--src/vod-multi-source.e2e.ts