Bump AetherEngine to 6.30.1 (partial mitigation for a backward-seek freeze) - #89
Merged
Merged
Conversation
…-seek freeze Repro (found while testing the skippable-segments/Up Next branch on the Simulator): scrub to within a few seconds of an asset's end, then scrub back to the middle — playback fails to resume, current-time label counts up briefly then stops entirely. Traced every seek path this app's own Swift code owns (PlayerViewModel.seek(to:) / AetherPlaybackEngine.seek(to:)) — both unchanged in shape by the skippable-segments branch, and nothing else issues a seek automatically around this moment. Ruled out as an app- level bug. Read AetherEngine's checked-out source at the previously-pinned 6.21.1: Video/Issue65LivelockBreakers.swift is a dedicated "stuck seek" detector, and AetherEngine+Loading.swift carries multiple "#93 round 3"/"#93 residual" comments through the seek/producer- restart machinery. Upstream issue #93 ("a single backward seek ... can wedge the segment producer") is closed but its own notes say residual wedging "occasionally persists" even after the fix rounds already baked into 6.21.1 — matching this report's shape closely (an earlier seek succeeds, a later single backward one wedges). Changelog entries between 6.21.1 and 6.30.1 keep touching this exact area (6.25.2's wedge detector arming, 6.29.0's backward-read handling), so this is an actively-maintained fix, not something abandoned at 6.21.1. Not a regression from the skippable-segments work — that feature just gives users a new, legitimate reason to scrub right up against an asset's tail and back, an interaction pattern that wasn't common before and happens to be exactly the shape of this known engine bug. project.yml's `from: 6.5.5` constraint already permitted 6.30.1 (SPM's "up to next major" rule); Package.resolved just hadn't re-resolved since it was already locked. Forced a fresh resolution (clearing DerivedData's cached SPM workspace state, since a plain -resolvePackageDependencies reused the stale lock) and regenerated AetherEngineVersion.swift via Scripts/update-aetherengine-version.sh per the documented process. Full test suite (469 tests) unaffected. Confirmed live (2026-08-18) post-bump: still reproducible on the Simulator, roughly 50% of attempts with the exact same repro — matches the upstream issue's own "occasionally persists" hedge. This is a partial mitigation, not a confirmed fix; keeping it regardless since it's still the latest upstream release with continued work in this exact area, and worth monitoring further AetherEngine updates for. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Bumps the pinned AetherEngine version from 6.21.1 → 6.30.1.
Why
Found while testing the skippable-segments/Up Next branch on the Simulator: scrub to within a few seconds of an asset's end (Up Next shows correctly), then scrub back to the middle — playback fails to resume, the current-time label counts up briefly then stops entirely.
Traced every seek path this app's own Swift code owns (
PlayerViewModel.seek(to:)/AetherPlaybackEngine.seek(to:)) — both unmodified passthroughs, unaffected by the skippable-segments branch. Not an app-level bug.Read AetherEngine's own checked-out source at the previously-pinned 6.21.1 and found a dedicated "stuck seek" detector (
Video/Issue65LivelockBreakers.swift) plus extensive#93 round N/#93 residualcomments through the seek/producer-restart machinery. This matches upstream AetherEngine#93 — "a single backward seek ... can wedge the segment producer" — closed, but its own notes admit residual wedging "occasionally persists" even after the fix rounds already baked into 6.21.1. Changelog entries between 6.21.1 and 6.30.1 keep touching this exact area, so it's an actively-maintained class of fix, not something abandoned.Not a regression from the skippable-segments work itself — that feature just gives users a new, legitimate reason to scrub right up to an asset's tail and back, an interaction pattern nobody had reason to exercise before, which happens to be exactly the shape of this known engine bug.
Status: partial mitigation, not a confirmed fix
Confirmed live post-bump: still reproducible on the Simulator, roughly 50% of attempts with the exact same repro — consistent with the upstream issue's own "occasionally persists" hedge. Keeping this bump regardless (latest upstream release, continued work in this exact area), and flagging it as something to keep an eye on for future AetherEngine updates rather than something fully resolved here.
How
project.yml'sfrom: 6.5.5constraint already permitted 6.30.1 (SPM's "up to next major" rule) —Package.resolvedjust hadn't re-resolved since it was already locked. Had to clear DerivedData's cached SPM workspace state (a plain-resolvePackageDependenciesreused the stale lock even after deleting the project's ownPackage.resolved), then regeneratedAetherEngineVersion.swiftviaScripts/update-aetherengine-version.shper the documented process.Testing
Full test suite (469 tests) passes unaffected — this is a dependency-only change with no app code touched beyond the generated version constant.
🤖 Generated with Claude Code