* feat(playback): record recently viewed only after the stream plays
A channel, movie or episode used to enter Recently Viewed (and the
dashboard's Continue Watching hero) the moment it was selected or its
link was resolved, so streams that failed straight away cluttered the
history.
Writers now defer the write to a root PlaybackHistoryGate, keyed by the
stream URL and/or the playback session key. The inline players confirm
those keys once the owned engine's position has advanced by two seconds
(seeks, stalls, pauses and a previous stream's progress do not count),
the radio player does the same, and a launched MPV/VLC session confirms
on `opened`/`playing`. M3U with MPV/VLC configured keeps recording on
selection. Covers M3U (live, radio, movie detail), Stalker (live, radio,
VOD, series), Xtream VOD and series, and the global live collection.
The M3U host's embeddedPlayback is now compared by value: the history
write updates the playlist meta mid-playback, and a new but identical
playback object remounted the engine and restarted the stream.
E2E flows that relied on recording-on-click now play local fixtures
(HLS/TS/WebM routed in place of unreachable or public streams) and wait
for confirmed playback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): tighten recently viewed confirmation per review
- Correlate by session key first: when both the deferred write and the
confirmation carry a playbackSessionKey, only that is compared, so the
same stream URL played in another playlist no longer records a failed
attempt. URLs remain the fallback (portal writes, MPV/VLC sessions).
The M3U radio player now receives the host's session key.
- Count only playing progress: engines report `playing` (not paused, not
seeking) with each time update, so short seeks of paused media no
longer confirm a view.
- Xtream: a write confirmed after a playlist switch still saves to its own
playlist but no longer replaces the current playlist's recent list.
- Global live tab: a row confirmed after another row was selected still
moves to the top of an open Recently Viewed list (only a disposed tab
skips the notification).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): confirm session-keyed history only by its own session
A write deferred with a playback session key (M3U) is now confirmed only
by that key. The app-wide MPV/VLC session confirmation carries just the
URL, so opening the same stream externally from another playlist could
still commit an abandoned attempt. An "Open in MPV/VLC" recovery launch is
instead confirmed by the WebPlayerViewComponent that requested it, under
its own session key, once the launch has opened.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* perf(playback): keep the history gate off the initial bundle
The `@iptvnator/services` barrel ships in the initial bundle, so adding
PlaybackHistoryGate there (and subscribing to it from the app-wide
ExternalPlaybackService) grew renderer.initialBytes by 1,141 bytes.
- Move the gate to a new lazy-only `playback-data-access` project
(`@iptvnator/playback/data-access`; scope:shared, domain:playback,
type:data-access) and register it in the coverage policy.
- The gate subscribes to MPV/VLC session updates itself; it is created by
the first deferred write, which precedes the launch it waits for.
ExternalPlaybackService is back to master.
- The Xtream "playlist switched before confirmation" check moves to the
lazy helper; the initial-path store only takes a `skipListRefresh` flag.
Net effect on this branch: +27 bytes over master (master itself is
108 bytes over the ratchet baseline already).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* perf(playback): drop late Xtream confirmations off the initial path
The Xtream store ships in the initial bundle, so even the small
`skipListRefresh` flag cost 27 bytes there. A confirmation can only
arrive after a switch to another playlist from a slow MPV/VLC launch
(the inline player goes with the page), so the lazy helper now drops it
instead: recording it would misfile the item or replace the other
playlist's recent list. with-recent-items is back to master.
This branch is now 3 bytes below master on renderer.initialBytes; the
ratchet still reports master's pre-existing overage.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(playback): pass the spec type-check gate from master
- playback-data-access: align tsconfig.spec.json with the epg-data-access
config #1705 updated (bundler resolution, global.d.ts for window.electron).
- M3U recent-history spec: type the selectSignal override.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): keep late Xtream confirmations in their own playlist history
A confirmation that arrives after a switch to another playlist (a slow
MPV/VLC launch) is no longer dropped: the lazy helper saves it to the
captured playlist through the data source, without reloading the store's
recent list, which belongs to the other playlist by then. The store and its
barrel ship in the initial bundle, so the save path stays in the feature
helper; renderer.initialBytes stays under the baseline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): correlate global live-tab history by its session key
The unified Favorites/Recent live tab deferred its history write by stream
URL only, so the same URL played from another playlist could confirm a
failed selection, and a switch to catch-up before confirmation could never
match. It now defers with the tab's playlist-scoped playbackSessionKey (the
key its players confirm with), and the tab's radio player receives it too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): keep MPV/VLC rows of the live tab confirmable by URL
The live tab's session key can only be confirmed by its own inline
players; MPV/VLC confirm the launched URL alone. A row that goes to an
external player (also later, after a double-click) now defers by URL, and
only rows played inline carry the session key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(playback): per-channel M3U history attempts, capability-based Xtream fallback
- M3U: the recently-viewed dedupe key now includes the channel id, so a
second row of the same URL defers its own write (its session key) and
is recorded when it plays after the first row failed.
- Xtream late write: key uncached content by Xtream id per
supportsXtreamSqliteDataSource (the data-source factory's contract), not
by a generic Electron bridge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: 4gray <fourgray@proton.me>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Xtream and Stalker live cards on the dashboard carried no XMLTV key, so the
rails never asked anything for them and showed only the LIVE chip. Their
programme now comes from the portal, one card at a time and only once the card
is on screen.
- `lib-dashboard-rail` reports the cards inside its viewport through an
IntersectionObserver rooted at the track; `DashboardLiveEpgPresenter` unions
them with the pinned hero row and hands the set to
`DashboardPortalLiveEpgPresenter`.
- `DashboardPortalLiveEpgService` runs the bounded queue — two requests in
flight, 200 ms apart, one card each — through
`StreamResolverService.loadEpgForItems`, publishing every answer the moment
it lands, so the page never waits and a slow portal delays no other card. A
card scrolled past before its turn is never requested.
- A programme is trusted for 60 s, an empty answer for 30 s (the resolver
reports a dead portal and a guide-less channel identically), and a
completion captures both the display offset and the EPG source revision,
requeueing itself when either moved.
- The presenter hands its wanted set back on destroy. Desktop only: the shared
collection resolver is gated on the local XMLTV bridge.
- A shimmer placeholder shows only before a card's first portal answer; M3U
cards keep the batched XMLTV lookup.
Movie and series detail pages showed two arrow_back controls while the
inline player was open: the shell's sticky arrow (added in #1576 so Back
survives scrolling) meant "Close player" in watch state, while the
now-playing bar carried a second arrow that meant route-level Back — the
same icon with two meanings, next to a "Close player" button that
duplicated the first.
The shell's sticky arrow is now route-level Back in browse and watch
alike, and the bar carries no arrow of its own. Closing the player is
the bar's "Close player" button and Escape, which still unwinds one
level (close, then back). Hosts without a browse Back target (M3U,
downloads) render no arrow in either state.
Unit specs for the shell and the inline player cover the new contract;
the Electron and web E2E helpers that pressed Back from watch are
updated, and the M3U flow closes the player through the bar's button.
Docs, the mirrored CLAUDE.md/AGENTS.md paragraph and a release note
follow the change.
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* feat(portals): rework the VOD sources popup and action row
The Sources popup now anchors above its button and always fits on screen:
the overlay caps it to the space beside the chip, only the source list
scrolls so the header, search, filter chips and footer stay visible, and
it flips below the button when the space above is too small. Filter chips
(All / Available / HD+ / language) compose with the playlist search, and
"Available" runs check-all itself when nothing has been checked yet.
Expanded copy rows no longer repeat the playlist domain: each copy shows
its parsed language chip, the provider's raw stream title, and only the
tags that differ from the parent copy.
Availability checks run at most four at a time and settled verdicts are
remembered per movie and source for ten minutes, so reopening a movie no
longer re-contacts every foreign portal.
Favorites and Download become icon-only buttons with real state: a filled
heart when favorited, and a download icon that turns into a progress ring
and then a checkmark that reveals the finished file.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(portals): match the movie detail's icon-only favorite button
The Xtream movie detail's favorite control is now an icon-only button, so
the shared "add this detail to favorites" helpers no longer found it by
class. They are used against series and Stalker details too, which still
render the labeled variant, so they now select by accessible name — the
icon button carries the same label in aria-label.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(portals): keep provider playback for a downloaded movie
Once a movie is downloaded the primary button plays the local file, and
the sources popover only exists when another playlist carries the same
film. The icon-only rework left those as the only two paths, so a
downloaded movie in a single-playlist library had no way at all to stream
the provider's copy — the labeled action that used to do it was gone.
Restores it as an icon button beside the downloaded checkmark, under the
same condition the old one used.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Two Electron E2E regressions from this branch's redesigns:
1. Hiding the playlist switcher on /settings (a playlist-scoped control)
also hid the global "Add playlist" button, which lives in the same
header-actions block. A user configuring Settings before importing
their first source had no way to add a playlist — and the settings /
playlist-switcher E2E suites, which add a portal right after saving a
setting, timed out waiting for the button. The Add Playlist button is
a global action, so it now stays visible on Settings; only the
per-playlist context shortcut and bulk actions are hidden there.
2. dashboard-activation.e2e.ts asserted on `dashboard-global-favorites-
rail`, the mixed Favorites rail removed earlier in this branch. The
test now targets the v0.22 rails: live favorites resolve through the
favorites-first `dashboard-live-recent-rail`, and the played movie /
series resolve through `dashboard-continue-watching-rail` (renamed
from `dashboard-recently-watched-rail`). The movie-from-favorites
assertion was dropped — that dashboard surface no longer exists; the
favorites collection still has its own page-level coverage.
Verified locally: dashboard-activation, settings, and playlist-switcher
E2E specs all pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Simplified expect statements for channel items and content cards in favorites and recent tests.
- Added new tests for opening Xtream favorite movies and series inline from favorites without switching playlists.
- Enhanced existing tests to ensure consistent behavior when navigating back from detail views.
- Introduced utility function expectInlineCollectionDetail to reduce code duplication in inline detail checks.
- Improved error handling for back button clicks in detail views.
Entire-Checkpoint: c6e522b4276c
