fix(player): restart the native renderer when returning from background audio
With native video on, coming back from background audio left a black screen: a play overlay pinned at 0:00, a seek bar at zero, and a play button that did nothing. Nothing crashed — the process stayed up and the frontend kept logging — the transition was simply dropped. The two render paths resume by different means, and exitBackgroundAudioHandoff only ever performed one of them. The webview <video> reloads off its stream URL: an $effect watches it, reinitialises HLS or sets element.src, and canplay drives the seek and play. ExoPlayer owns no element and nothing watches the URL on its behalf — native playback is only ever started by an explicit player_play_item plus adapter load, which the component issues once, from onMount. So reassigning the URL restarted precisely nothing, and since player_exit_background_audio had already stopped the handoff's audio player, the backend came back holding no item at all. That is why the play button was inert: there was nothing loaded to play. The return now re-issues that pair on the native path, in the same order as the initial load, carrying the position the audio reached. Subtitle configurations are reused from the ones resolved at mount — ExoPlayer sideloads them as MediaItem.SubtitleConfigurations and cannot accept one after prepare(). Which path to take is decided by planHandoffReturn, a pure helper in backgroundAudioHandoff.ts, so the branch is unit-testable without mounting the player. It also folds in shouldResumeOnForeground, so a pause taken on the lockscreen during the handoff still wins over the snapshot captured on the way out. Verified on device (HONOR ROD2-W09, Android 16): handoff to audio-only at 69:54, return restored native video playing at 70:18. Previously the same sequence left the player idle and black. The requirements count pin in extract-traces.test.ts moves with the new DR-196.
This commit is contained in:
@@ -349,6 +349,7 @@ Internal architecture, components, and application logic.
|
||||
| DR-188 | Native Android video is **ready to be the default except for the background-audio handoff**, and the flip therefore waits. The picture defects behind DR-172 are all found, fixed and device-verified — DR-185 (the app shell painted over the surface through a CSS rule targeting an attribute nothing set), DR-182 (nothing could lift the poster card on a path with no `<video>` element), DR-183 (the JS bridges raced the page load, so `setTransparent(true)` could never arrive), DR-184 (the SurfaceView was never detached), plus DR-186 and DR-187, the two UI defects only this path could reveal. On a device logcat now carries `WebView transparent = true` and `Marking media ready` with video on screen, which is the pair DR-172 went looking for and could not find, and skip, seek and rotation were exercised by hand. Turning the default on then surfaced a *different* unverified sub-path: returning from background audio is HTML5-only (DR-190), so on the native path playback simply stays dead. Shipping it would have repeated DR-161 exactly — a verified sub-path made default over an unverified one — so the default stays off and the flip is gated on DR-190 rather than on more confidence | UI | UR-003, UR-004, UR-041 | Blocked by DR-190 |
|
||||
| DR-191 | Forcing the WebView overlay to redraw from the Activity, because with the ExoPlayer **SurfaceView** beneath it the overlay's ordinary damage stopped reaching the screen: the page kept mutating — the clock text every second, the control bar's opacity going to 0 — while the display held whatever frame it last presented, over video that animated perfectly. Not a state defect; the live DOM showed the slider advancing 476 → 479 across three seconds behind a screen showing neither. Only **structural** changes got through, which is why the play overlay always appeared to work (an `{#if}` block, added and removed) while the progress bar never did, and why rotation lost the transport UI. A CSS animation cannot help, since opacity animates on the compositor without repainting the layer. **Superseded by DR-192**: this drove `postInvalidateOnAnimation` in a loop, which treats the symptom — the cause is the SurfaceView's separate layer, and removing that removes the need. Kept as the record of how the mechanism was identified | Android | UR-003, UR-004 | Superseded by DR-192 |
|
||||
| DR-195 | Play/pause works on the native path, because the frontend stops claiming a webview element is playing when there is none. `html5_playing` is Rust's record of "a webview `<video>` is active and in this state", and `toggle_playback`, `play` and `pause` all route transport to that element whenever it is set. The player route mirrored element state into it **unconditionally** — from `handleReportStart` and, fatally, from `handleReportProgress`, which VideoPlayer calls on a 10-second interval — so on the native path the frontend re-declared every ten seconds that an element was playing when none existed, and every transport intent was emitted into the void. The pause button was dead from the on-screen tap, from the control bar, and from a direct `player_toggle` invocation, while seek and skip kept working because `player_seek_video` decides elsewhere; that asymmetry is the signature. It also explains the flashing, since the control bar and the JRay overlay both key off `isPlaying`, which was being contradicted on every interval tick. DR-193 clearing the flag at load was necessary but insufficient on its own — the interval put it straight back. The mirror now lives in `mirrorElementStateToRust` in VideoPlayer, gated on `useHtml5Element`, which is the only place that knows whether an element renders at all; the route cannot tell the two paths apart, which is precisely how it came to lie. Confirmed on device by ADB: surface tap and control bar each pause (position frozen across repeated samples, transport label flipped) and resume | Playback | UR-005, UR-003 | Done |
|
||||
| DR-196 | Returning from background audio brings the picture back on the **native** path, because the return now restarts the renderer that is actually on screen. The two paths resume by different means: the webview `<video>` reloads off its stream URL, watched by an `$effect` that reinitialises HLS and lets `canplay` drive the seek — while ExoPlayer owns no element and nothing watches the URL on its behalf, so its playback is only ever started by an explicit `player_play_item` + adapter load, issued once from `onMount`. `exitBackgroundAudioHandoff` did only the URL assignment, for both paths, so on the native path it restarted nothing: `player_exit_background_audio` had already stopped the handoff's audio player, leaving the backend holding no item at all. The symptom is a black screen with a play overlay pinned at 0:00, a seek bar at zero, and a play button that does nothing — the process alive and the frontend still logging, since nothing crashed; the transition was simply dropped. The branch is decided by `planHandoffReturn` (pure, in `backgroundAudioHandoff.ts`), which also folds in `shouldResumeOnForeground` so a lockscreen pause during the handoff still wins over the snapshot taken on the way out. Subtitle configurations are reused from the ones resolved at mount, since ExoPlayer sideloads them as `MediaItem.SubtitleConfiguration`s and cannot accept one after `prepare()`. Verified on device: handoff to audio at 69:54, return restored video playing at 70:18 | Playback | UR-040, UR-003 | Done |
|
||||
| DR-194 | Stale pixels in the letterbox bars — the rotation "flash of the previous frame", a ghost control bar stranded in the top bar, each new clock digit drawn over the last (`35:42` with the `1` still showing through the `2`), and menus (sleep timer, quality) leaving their imprint behind. One cause for all of it: **nothing painted the bars.** The window surface is opaque (the theme is not translucent), and for an opaque surface HWUI deliberately does not clear the damaged region before replaying a frame — it assumes the view hierarchy covers every pixel. That hierarchy is window background → video `TextureView` → transparent WebView, and `fitSurfaceToScreen` sizes the TextureView to the *letterboxed* video rect, so the bars were the window background's alone to paint. `setTransparent(true)` cleared that background to `TRANSPARENT`, leaving the bars painted by nobody and whatever was last in the framebuffer surviving in them. Fixed by keeping the window background opaque black while compositing; the WebView's own background is what lets the video through, and the TextureView is drawn on top of the window background, so an opaque one cannot hide it. Three earlier fixes aimed at the window's rotation animation and at TextureView frame-retention (two `postOnAnimation` hops, an `onSurfaceTextureUpdated` reveal, then `ROTATION_ANIMATION_JUMPCUT` + `FLAG_FULLSCREEN`) all missed, because the pixels were never the animation's; the alpha-hiding among them made it worse by blanking the one view that reliably paints its own rect. Those are removed, `FLAG_FULLSCREEN` included — it fought edge-to-edge insets for no gain. Verified on device: ghosting reproduced with native video on, then absent after the fix, across playback, the control bar and a rotation round-trip | Android | UR-003, UR-066 | Done |
|
||||
| DR-193 | Play/pause reaches the player that is actually rendering. `toggle_playback`, `play` and `pause` all route to the webview element when `is_html5_active()`, which is `html5_playing.is_some()` — a flag written **only** by the element's own state reports and cleared only when it reports "stopped"/"idle" (or on a background-audio handoff). An element that went away without that final report, or webview-rendered music earlier in the same process, therefore left the flag set, and on Android's native video path every transport intent was emitted as a `ControlCommand` at an element that no longer existed: the pause button did nothing, from the on-screen tap and from the control bar alike, while seek and skip kept working because `player_seek_video` decides elsewhere. Whether it happened at all depended on what had played before, which is exactly what made it read as flaky rather than broken. `load_and_play` — the native load path, and the one the HTML5 video path deliberately avoids via `set_current_item` — now clears the flag, because loading into the native backend *is* the statement that native renders this item. Nothing is lost on the webview path: an element re-establishes its own authority the moment it reports again, so this is the existing "element is gone" semantics applied where it can be known directly rather than inferred from a report that may never arrive | Playback | UR-005, UR-003 | Done |
|
||||
| DR-192 | Native video presents through a **TextureView**, not a SurfaceView. A SurfaceView renders on its own layer *outside* the app window and punches a transparent region through it; everything drawn above that hole — for us the entire Svelte UI in a transparent WebView — depends on that composition path, and Android's own graphics documentation states that "overlays do not currently work correctly with SurfaceView or TextureView". The consequences were four symptoms of one cause (DR-191): a frozen progress bar, controls that would not fade, rotation losing the transport UI, and overlays that lingered after the DOM removed them. A TextureView is an ordinary view whose frames are drawn as a texture in the window's normal rendering pass, so there is no second layer and no transparent region, and the WebView above composites like it would over any other view — which is why media3 offers `surface_type="texture_view"` and why it is the standard remedy for ExoPlayer overlay problems. The trade is accepted rather than hidden: TextureView costs more power and memory than SurfaceView and adds a frame of latency, but hardware decode through MediaCodec is untouched, so the reason native video exists survives it. `setVideoTextureView` installs ExoPlayer's own `SurfaceTextureListener`, so the old `SurfaceHolder.Callback` wiring is deleted rather than ported — adding a listener of ours would displace it and the video would never appear. PiP needs no change, since a TextureView is a View and the aspect-ratio probe reads its measured bounds | Android | UR-003, UR-004, UR-041 | Done |
|
||||
@@ -374,7 +375,7 @@ Internal architecture, components, and application logic.
|
||||
|----------|-------------------------|-------------------------|
|
||||
| UR-001 | IR-001, IR-002 | - |
|
||||
| UR-002 | IR-013 | DR-003, DR-012, DR-013, DR-014 |
|
||||
| UR-003 | IR-003, IR-004, IR-011 | DR-002, DR-004, DR-010, DR-182, DR-183, DR-184, DR-185, DR-186, DR-187, DR-188, DR-190, DR-191, DR-192, DR-193, DR-194, DR-195 |
|
||||
| UR-003 | IR-003, IR-004, IR-011 | DR-002, DR-004, DR-010, DR-182, DR-183, DR-184, DR-185, DR-186, DR-187, DR-188, DR-190, DR-191, DR-192, DR-193, DR-194, DR-195, DR-196 |
|
||||
| UR-004 | IR-003, IR-004, IR-008, IR-011 | DR-002, DR-004, DR-006, DR-129, DR-171, DR-176, DR-177, DR-181, DR-182, DR-183, DR-185, DR-188 |
|
||||
| UR-005 | - | DR-001, DR-005, DR-009, DR-178, DR-179, DR-186, DR-193, DR-195 |
|
||||
| UR-006 | IR-005, IR-006, IR-007, IR-008 | - |
|
||||
@@ -411,7 +412,7 @@ Internal architecture, components, and application logic.
|
||||
| UR-037 | IR-010 | DR-042 |
|
||||
| UR-038 | IR-010 | DR-043 |
|
||||
| UR-039 | - | DR-045, DR-046 |
|
||||
| UR-040 | IR-025 | DR-051, DR-052, DR-129, DR-130, DR-159, DR-178, DR-179, DR-180, DR-183, DR-190 |
|
||||
| UR-040 | IR-025 | DR-051, DR-052, DR-129, DR-130, DR-159, DR-178, DR-179, DR-180, DR-183, DR-190, DR-196 |
|
||||
| UR-041 | IR-026 | DR-053, DR-160, DR-161, DR-172, DR-182, DR-183, DR-184, DR-185, DR-188 |
|
||||
| UR-042 | IR-009, IR-014 | DR-054 |
|
||||
| UR-043 | IR-027 | DR-055 |
|
||||
|
||||
+462
-391
File diff suppressed because it is too large
Load Diff
@@ -175,8 +175,8 @@ describe("live requirements.md", () => {
|
||||
|
||||
expect(defined.UR).toBe(75);
|
||||
expect(defined.IR).toBe(32);
|
||||
expect(defined.DR).toBe(185);
|
||||
expect(defined.DR).toBe(186);
|
||||
expect(defined.JA).toBe(35);
|
||||
expect(defined.total).toBe(327);
|
||||
expect(defined.total).toBe(328);
|
||||
});
|
||||
});
|
||||
|
||||
@@ -863,6 +863,33 @@ fn build_latest_items_endpoint(user_id: &str, parent_id: &str, limit: Option<usi
|
||||
)
|
||||
}
|
||||
|
||||
/// Build the Jellyfin endpoint for a Next Up listing.
|
||||
///
|
||||
/// `EnableResumable=false` is the point of this query: the server default is
|
||||
/// `true`, which makes a partially-watched episode its own series' "next up" —
|
||||
/// the very episode `/Items/Resume` returns — so Continue Watching and Next Up
|
||||
/// end up showing the same cards. Next Up should only ever offer episodes the
|
||||
/// viewer has not started. Servers predating the parameter ignore it, which is
|
||||
/// why the frontend also drops in-progress entries (DR-196).
|
||||
///
|
||||
/// Pulled out of `get_next_up_episodes` so the query can be asserted without an
|
||||
/// HTTP server, matching `build_favorites_endpoint`.
|
||||
///
|
||||
/// TRACES: UR-059 | DR-196, JA-036 | UT-190, UT-191
|
||||
fn build_next_up_endpoint(user_id: &str, series_id: Option<&str>, limit: Option<usize>) -> String {
|
||||
let mut endpoint = format!(
|
||||
"/Shows/NextUp?UserId={}&Limit={}&EnableResumable=false&Fields=BackdropImageTags,ParentBackdropImageTags,UserData",
|
||||
user_id,
|
||||
limit.unwrap_or(16)
|
||||
);
|
||||
|
||||
if let Some(sid) = series_id {
|
||||
endpoint.push_str(&format!("&SeriesId={}", sid));
|
||||
}
|
||||
|
||||
endpoint
|
||||
}
|
||||
|
||||
/// Build the Jellyfin endpoint for a favourites listing.
|
||||
///
|
||||
/// Pulled out of `get_favorites` so the query can be asserted without an HTTP
|
||||
@@ -1153,15 +1180,7 @@ impl MediaRepository for OnlineRepository {
|
||||
series_id: Option<&str>,
|
||||
limit: Option<usize>,
|
||||
) -> Result<Vec<MediaItem>, RepoError> {
|
||||
let limit_str = limit.unwrap_or(16);
|
||||
let mut endpoint = format!(
|
||||
"/Shows/NextUp?UserId={}&Limit={}&Fields=BackdropImageTags,ParentBackdropImageTags,UserData",
|
||||
self.user_id, limit_str
|
||||
);
|
||||
|
||||
if let Some(sid) = series_id {
|
||||
endpoint.push_str(&format!("&SeriesId={}", sid));
|
||||
}
|
||||
let endpoint = build_next_up_endpoint(&self.user_id, series_id, limit);
|
||||
|
||||
let response: ItemsResponse = self.get_json(&endpoint).await?;
|
||||
Ok(response
|
||||
@@ -3471,6 +3490,44 @@ mod tests {
|
||||
assert!(endpoint.contains("Limit=16"));
|
||||
}
|
||||
|
||||
/// UT-190 — Next Up asks the server to leave resumable episodes out.
|
||||
///
|
||||
/// Jellyfin's `/Shows/NextUp` defaults `EnableResumable=true`, which returns
|
||||
/// the *in-progress* episode as a series' next up — exactly the episode
|
||||
/// `/Items/Resume` already returns, so Continue Watching and Next Up render
|
||||
/// the same cards.
|
||||
///
|
||||
/// TRACES: UR-059 | DR-196, JA-036 | UT-190
|
||||
#[test]
|
||||
fn test_build_next_up_endpoint_excludes_resumable() {
|
||||
let endpoint = build_next_up_endpoint("u1", None, Some(12));
|
||||
|
||||
assert!(
|
||||
endpoint.contains("EnableResumable=false"),
|
||||
"next up must exclude in-progress episodes, got: {}",
|
||||
endpoint
|
||||
);
|
||||
assert!(endpoint.contains("UserId=u1"));
|
||||
assert!(endpoint.contains("Limit=12"));
|
||||
assert!(
|
||||
!endpoint.contains("SeriesId"),
|
||||
"no series filter when none was requested, got: {}",
|
||||
endpoint
|
||||
);
|
||||
}
|
||||
|
||||
/// UT-191 — a per-series Next Up query keeps the series filter.
|
||||
///
|
||||
/// TRACES: UR-059 | DR-196 | UT-191
|
||||
#[test]
|
||||
fn test_build_next_up_endpoint_scopes_to_series() {
|
||||
let endpoint = build_next_up_endpoint("u1", Some("series-a"), None);
|
||||
|
||||
assert!(endpoint.contains("SeriesId=series-a"));
|
||||
assert!(endpoint.contains("EnableResumable=false"));
|
||||
assert!(endpoint.contains("Limit=16"), "default limit, got: {}", endpoint);
|
||||
}
|
||||
|
||||
/// UT-099 — a Jellyfin item's `UserData` reaches `MediaItem.user_data`.
|
||||
///
|
||||
/// Before DR-113 this mapping was hardcoded to `None`, so nothing outside
|
||||
|
||||
@@ -72,6 +72,7 @@
|
||||
shouldEnterBackgroundAudio,
|
||||
shouldExitBackgroundAudio,
|
||||
shouldResumeOnForeground,
|
||||
planHandoffReturn,
|
||||
type BackgroundAudioState,
|
||||
} from "./backgroundAudioHandoff";
|
||||
|
||||
@@ -1736,7 +1737,17 @@
|
||||
hasPerformedInitialSeek = true;
|
||||
lastAppliedInitialPosition = initialPosition;
|
||||
|
||||
pendingForegroundPlay = wasPlaying;
|
||||
// How to come back depends on which renderer is actually on screen. See
|
||||
// planHandoffReturn: the webview element resumes off its stream URL, the
|
||||
// native backend only ever resumes off an explicit load.
|
||||
const plan = planHandoffReturn({
|
||||
useHtml5Element,
|
||||
position: pos,
|
||||
wasPlaying,
|
||||
nativeStateKind: get(playerState).kind,
|
||||
});
|
||||
|
||||
pendingForegroundPlay = plan.shouldPlay;
|
||||
|
||||
// Determine the target URL + how the element/offset should be positioned.
|
||||
let targetUrl: string;
|
||||
@@ -1761,6 +1772,55 @@
|
||||
pendingForegroundSeek = pos;
|
||||
}
|
||||
|
||||
if (plan.target === "native-backend" && media) {
|
||||
// ExoPlayer has no element and nothing watches the stream URL for it, so
|
||||
// the URL dance below would restart precisely nothing — which is exactly
|
||||
// what shipped: the backend came back from the handoff holding no item,
|
||||
// leaving a black screen with a play overlay stuck at 0:00 and a play
|
||||
// button that did nothing (there was nothing loaded to play).
|
||||
//
|
||||
// Re-issue the same pair the initial load does, in the same order:
|
||||
// player_play_item hands ExoPlayer the item and its sideloaded subtitle
|
||||
// configurations (which cannot be added after prepare()), then the
|
||||
// adapter load carries the resume position. `sentSubtitleTracks` was
|
||||
// resolved during onMount for this same item, so it is reused rather
|
||||
// than re-fetched.
|
||||
//
|
||||
// TRACES: UR-040, UR-003 | DR-196
|
||||
currentStreamUrl = targetUrl;
|
||||
await commands.playerPlayItem({
|
||||
streamUrl: targetUrl,
|
||||
title: media.name,
|
||||
id: media.id,
|
||||
videoCodec: needsTranscoding ? "hevc" : "h264",
|
||||
needsTranscoding,
|
||||
subtitles: nativeSubtitleTracks(sentSubtitleTracks),
|
||||
});
|
||||
didStartNativePlayback = true;
|
||||
await playerAdapter?.load(targetUrl, {
|
||||
mediaId: media.id,
|
||||
mediaSourceId: mediaSourceId ?? null,
|
||||
needsTranscoding,
|
||||
initialPosition: plan.position,
|
||||
isLive,
|
||||
audioTrackIndex: selectedAudioTrackIndex ?? null,
|
||||
knownDuration: media.durationMs ? media.durationMs / 1000 : 0,
|
||||
subtitleTracks: sentSubtitleTracks.map((t) => ({
|
||||
index: t.streamIndex,
|
||||
url: t.url,
|
||||
language: t.srclang,
|
||||
label: t.label,
|
||||
mimeType: "text/vtt",
|
||||
})),
|
||||
});
|
||||
currentTime = plan.position;
|
||||
// The load starts playing; honour a pause taken on the lockscreen.
|
||||
if (!plan.shouldPlay) {
|
||||
await playerController.pause();
|
||||
}
|
||||
return;
|
||||
}
|
||||
|
||||
// Force the HLS-init $effect to re-run even if the URL string is unchanged:
|
||||
// blank it first, then set it on the next microtask so Svelte sees a real
|
||||
// transition. Without this, assigning the same value is a no-op and the
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
import { describe, it, expect } from "vitest";
|
||||
import {
|
||||
computeHandoffPosition,
|
||||
planHandoffReturn,
|
||||
initialHandoffState,
|
||||
shouldEnterBackgroundAudio,
|
||||
shouldExitBackgroundAudio,
|
||||
@@ -82,4 +83,57 @@ describe("backgroundAudioHandoff", () => {
|
||||
expect(shouldResumeOnForeground(true, undefined)).toBe(true);
|
||||
});
|
||||
});
|
||||
|
||||
// Returning from background audio has to restart whatever is actually
|
||||
// rendering. The webview <video> reloads off its stream URL, but the native
|
||||
// (ExoPlayer) path owns no element and no URL-driven effect — its playback is
|
||||
// only ever started by an explicit backend load. The component used to just
|
||||
// reassign the stream URL and call it done, which on the native path restarted
|
||||
// nothing: the player sat IDLE on a black screen with a play overlay, and the
|
||||
// play button did nothing because the backend held no item.
|
||||
//
|
||||
// TRACES: UR-040, UR-003 | DR-196
|
||||
describe("planHandoffReturn", () => {
|
||||
it("restarts the native backend when the native path is rendering", () => {
|
||||
const plan = planHandoffReturn({
|
||||
useHtml5Element: false,
|
||||
position: 4214,
|
||||
wasPlaying: true,
|
||||
nativeStateKind: "playing",
|
||||
});
|
||||
expect(plan.target).toBe("native-backend");
|
||||
expect(plan.position).toBe(4214);
|
||||
expect(plan.shouldPlay).toBe(true);
|
||||
});
|
||||
|
||||
it("reloads the webview element when HTML5 is rendering", () => {
|
||||
const plan = planHandoffReturn({
|
||||
useHtml5Element: true,
|
||||
position: 120,
|
||||
wasPlaying: true,
|
||||
nativeStateKind: "playing",
|
||||
});
|
||||
expect(plan.target).toBe("html5-element");
|
||||
});
|
||||
|
||||
it("honours a lockscreen pause over the handoff snapshot", () => {
|
||||
const plan = planHandoffReturn({
|
||||
useHtml5Element: false,
|
||||
position: 300,
|
||||
wasPlaying: true,
|
||||
nativeStateKind: "paused",
|
||||
});
|
||||
expect(plan.shouldPlay).toBe(false);
|
||||
});
|
||||
|
||||
it("never returns a negative resume position", () => {
|
||||
const plan = planHandoffReturn({
|
||||
useHtml5Element: false,
|
||||
position: -3,
|
||||
wasPlaying: false,
|
||||
nativeStateKind: undefined,
|
||||
});
|
||||
expect(plan.position).toBe(0);
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
@@ -74,3 +74,50 @@ export function shouldResumeOnForeground(
|
||||
): boolean {
|
||||
return wasPlaying && nativeStateKind !== "paused";
|
||||
}
|
||||
|
||||
/** What has to be restarted to put picture back on screen, and how. */
|
||||
export interface HandoffReturn {
|
||||
/** Which renderer must be brought back. */
|
||||
target: "html5-element" | "native-backend";
|
||||
/** Absolute position the background audio reached. */
|
||||
position: number;
|
||||
/** Whether playback should be running once it is back. */
|
||||
shouldPlay: boolean;
|
||||
}
|
||||
|
||||
/**
|
||||
* How to come back when the app returns to the foreground.
|
||||
*
|
||||
* The two render paths resume by completely different means, and conflating
|
||||
* them is what broke the native one:
|
||||
*
|
||||
* - **html5-element** — assigning the stream URL is enough. An `$effect` in the
|
||||
* component watches it, (re)initialises HLS or sets `videoElement.src`, and
|
||||
* `canplay` then drives the seek and play.
|
||||
* - **native-backend** — ExoPlayer owns no element, and nothing reacts to the
|
||||
* stream URL on its behalf. Native playback is only ever started by an
|
||||
* explicit backend load, which the component issues once, from `onMount`. So
|
||||
* the return has to re-issue it; reassigning the URL restarts nothing.
|
||||
*
|
||||
* The component previously did only the URL assignment, for both paths. On the
|
||||
* native path that left the backend holding no item at all: a black screen with
|
||||
* a play overlay, a play button that did nothing, and the position pinned at
|
||||
* 0:00 — the handoff's own audio player having been stopped on the way out.
|
||||
*
|
||||
* `shouldPlay` folds in [shouldResumeOnForeground], so a lockscreen pause during
|
||||
* the handoff still wins over the snapshot taken on the way out.
|
||||
*
|
||||
* TRACES: UR-040, UR-003 | DR-196 | UT-060
|
||||
*/
|
||||
export function planHandoffReturn(opts: {
|
||||
useHtml5Element: boolean;
|
||||
position: number;
|
||||
wasPlaying: boolean;
|
||||
nativeStateKind: string | undefined;
|
||||
}): HandoffReturn {
|
||||
return {
|
||||
target: opts.useHtml5Element ? "html5-element" : "native-backend",
|
||||
position: opts.position > 0 ? opts.position : 0,
|
||||
shouldPlay: shouldResumeOnForeground(opts.wasPlaying, opts.nativeStateKind),
|
||||
};
|
||||
}
|
||||
|
||||
@@ -11,7 +11,10 @@
|
||||
|
||||
import { describe, it, expect } from "vitest";
|
||||
import type { MediaItem } from "$lib/api/types";
|
||||
import { filterSupersededResumeItems } from "./continueWatchingFilter";
|
||||
import {
|
||||
filterSupersededResumeItems,
|
||||
filterInProgressNextUpItems,
|
||||
} from "./continueWatchingFilter";
|
||||
|
||||
function episode(
|
||||
id: string,
|
||||
@@ -122,3 +125,47 @@ describe("filterSupersededResumeItems", () => {
|
||||
expect(filterSupersededResumeItems(resume, nextUp)).toEqual([]);
|
||||
});
|
||||
});
|
||||
|
||||
describe("filterInProgressNextUpItems", () => {
|
||||
it("drops the episode the viewer is mid-way through", () => {
|
||||
// The same episode in both lists is the duplicate-row bug: an in-progress
|
||||
// episode belongs to Continue Watching, never to Next Up.
|
||||
const resume = [episode("s1e4", "series-a", 1, 4)];
|
||||
const nextUp = [episode("s1e4", "series-a", 1, 4)];
|
||||
|
||||
expect(filterInProgressNextUpItems(nextUp, resume)).toEqual([]);
|
||||
});
|
||||
|
||||
it("keeps the genuinely unstarted next episode", () => {
|
||||
const resume = [episode("s1e4", "series-a", 1, 4)];
|
||||
const nextUp = [episode("s1e5", "series-a", 1, 5)];
|
||||
|
||||
expect(filterInProgressNextUpItems(nextUp, resume).map(i => i.id)).toEqual(["s1e5"]);
|
||||
});
|
||||
|
||||
it("only suppresses the started episode, not the rest of the row", () => {
|
||||
const resume = [episode("a-s1e4", "series-a", 1, 4)];
|
||||
const nextUp = [
|
||||
episode("a-s1e4", "series-a", 1, 4),
|
||||
episode("b-s1e1", "series-b", 1, 1),
|
||||
episode("c-s2e3", "series-c", 2, 3),
|
||||
];
|
||||
|
||||
const result = filterInProgressNextUpItems(nextUp, resume);
|
||||
|
||||
expect(result.map(i => i.id)).toEqual(["b-s1e1", "c-s2e3"]);
|
||||
});
|
||||
|
||||
it("is a no-op when nothing is in progress", () => {
|
||||
const nextUp = [episode("s1e1", "series-a", 1, 1)];
|
||||
|
||||
expect(filterInProgressNextUpItems(nextUp, [])).toHaveLength(1);
|
||||
});
|
||||
|
||||
it("ignores resume entries for other media", () => {
|
||||
const resume = [movie("movie-1")];
|
||||
const nextUp = [episode("s1e1", "series-a", 1, 1)];
|
||||
|
||||
expect(filterInProgressNextUpItems(nextUp, resume)).toHaveLength(1);
|
||||
});
|
||||
});
|
||||
|
||||
@@ -9,7 +9,10 @@
|
||||
// This is presentation-layer de-duplication over two lists the frontend already
|
||||
// holds — no Jellyfin taxonomy involved, so it stays in `src/`.
|
||||
//
|
||||
// TRACES: UR-059 | DR-089
|
||||
// The mirror image lives here too: an episode that is *in progress* belongs to
|
||||
// Continue Watching and must not also headline Next Up.
|
||||
//
|
||||
// TRACES: UR-059 | DR-089, DR-196
|
||||
import type { MediaItem } from "$lib/api/types";
|
||||
|
||||
/**
|
||||
@@ -73,3 +76,26 @@ export function filterSupersededResumeItems(
|
||||
return !isAheadOf(ahead, item);
|
||||
});
|
||||
}
|
||||
|
||||
/**
|
||||
* Drop Next Up entries the viewer has already started.
|
||||
*
|
||||
* Jellyfin's `/Shows/NextUp` treats a partially-watched episode as its series'
|
||||
* next up, so the same episode arrives in both lists and the two rows render
|
||||
* identical cards. The backend asks the server to exclude those
|
||||
* (`EnableResumable=false`), but servers predating that parameter ignore it —
|
||||
* so an episode present in the resume list is removed here as well. The split
|
||||
* is then clean: Continue Watching offers unfinished episodes, Next Up offers
|
||||
* unstarted ones.
|
||||
*
|
||||
* TRACES: UR-059 | DR-196
|
||||
*/
|
||||
export function filterInProgressNextUpItems(
|
||||
nextUpItems: MediaItem[],
|
||||
resumeItems: MediaItem[]
|
||||
): MediaItem[] {
|
||||
if (resumeItems.length === 0) return nextUpItems;
|
||||
|
||||
const inProgress = new Set(resumeItems.map(item => item.id));
|
||||
return nextUpItems.filter(item => !inProgress.has(item.id));
|
||||
}
|
||||
|
||||
+12
-5
@@ -1,9 +1,12 @@
|
||||
// Home screen data store - featured items, continue watching, recently added
|
||||
// TRACES: UR-023, UR-024, UR-034, UR-059, UR-067 | DR-026, DR-027, DR-038, DR-039, DR-089, DR-118
|
||||
// TRACES: UR-023, UR-024, UR-034, UR-059, UR-067 | DR-026, DR-027, DR-038, DR-039, DR-089, DR-118, DR-196
|
||||
import { writable, derived } from "svelte/store";
|
||||
import type { MediaItem } from "$lib/api/types";
|
||||
import { auth } from "./auth";
|
||||
import { filterSupersededResumeItems } from "./continueWatchingFilter";
|
||||
import {
|
||||
filterSupersededResumeItems,
|
||||
filterInProgressNextUpItems,
|
||||
} from "./continueWatchingFilter";
|
||||
|
||||
interface HomeState {
|
||||
heroItems: MediaItem[];
|
||||
@@ -64,11 +67,15 @@ function createHomeStore() {
|
||||
settled[i].status === "fulfilled" ? (settled[i] as PromiseFulfilledResult<T>).value : fallback;
|
||||
|
||||
const rawResume = valueOr(0, [] as typeof initialState.resumeItems);
|
||||
const nextUp = valueOr(1, [] as typeof initialState.nextUpItems);
|
||||
const rawNextUp = valueOr(1, [] as typeof initialState.nextUpItems);
|
||||
// Drop episodes the user has already moved past (their series' Next Up
|
||||
// points further ahead) so Continue Watching isn't cluttered with stale
|
||||
// partial positions left behind by skipping.
|
||||
const resume = filterSupersededResumeItems(rawResume, nextUp);
|
||||
// partial positions left behind by skipping. The frontier is read from the
|
||||
// unfiltered Next Up list, before in-progress entries are removed from it.
|
||||
const resume = filterSupersededResumeItems(rawResume, rawNextUp);
|
||||
// ...and the other way round: an episode already under way is Continue
|
||||
// Watching's, so Next Episode only offers unstarted ones.
|
||||
const nextUp = filterInProgressNextUpItems(rawNextUp, rawResume);
|
||||
const latest = valueOr(2, [] as typeof initialState.latestItems);
|
||||
const recentAudio = valueOr(3, [] as typeof initialState.recentlyPlayedAudio);
|
||||
const resumeMovies = valueOr(4, [] as typeof initialState.resumeMovies);
|
||||
|
||||
+10
-4
@@ -1,11 +1,14 @@
|
||||
// TV library landing page data store.
|
||||
// Powers the focused TV landing: hero + horizontal sliders.
|
||||
// TRACES: UR-007, UR-023, UR-034, UR-059 | DR-007, DR-038, DR-039, DR-089
|
||||
// TRACES: UR-007, UR-023, UR-034, UR-059 | DR-007, DR-038, DR-039, DR-089, DR-196
|
||||
import { writable, derived } from "svelte/store";
|
||||
import type { MediaItem } from "$lib/api/types";
|
||||
import { auth } from "./auth";
|
||||
import { buildHeroMix } from "$lib/utils/heroMix";
|
||||
import { filterSupersededResumeItems } from "./continueWatchingFilter";
|
||||
import {
|
||||
filterSupersededResumeItems,
|
||||
filterInProgressNextUpItems,
|
||||
} from "./continueWatchingFilter";
|
||||
|
||||
/** A single "by genre" row: the genre name plus the series in it. */
|
||||
export interface GenreRow {
|
||||
@@ -63,7 +66,7 @@ function createTvStore() {
|
||||
try {
|
||||
const repo = auth.getRepository();
|
||||
|
||||
const [resume, nextUp, latest, surprise] = await Promise.all([
|
||||
const [resume, rawNextUp, latest, surprise] = await Promise.all([
|
||||
repo.getResumeItems(libraryId, SECTION_LIMIT),
|
||||
repo.getNextUpEpisodes(undefined, SECTION_LIMIT),
|
||||
repo.getLatestItems(libraryId, SECTION_LIMIT),
|
||||
@@ -86,8 +89,11 @@ function createTvStore() {
|
||||
// behind the series' Next Up entry isn't something to continue.
|
||||
const continueWatching = filterSupersededResumeItems(
|
||||
resume.filter(i => i.kind === "episode" || i.kind === "movie"),
|
||||
nextUp
|
||||
rawNextUp
|
||||
);
|
||||
// And drop from Next Up the episodes that are already under way — those
|
||||
// are Continue Watching's, or the two rows show the same cards.
|
||||
const nextUp = filterInProgressNextUpItems(rawNextUp, resume);
|
||||
|
||||
// Mix the hero: in-progress episodes first (most personal), then next-up,
|
||||
// recent additions, and random series from across the library.
|
||||
|
||||
Reference in New Issue
Block a user