Skip to content

Bump AetherEngine to 6.30.1 (partial mitigation for a backward-seek freeze) - #89

Merged
imbenjamin merged 1 commit into
developfrom
fix/aetherengine-seek-wedge
Aug 18, 2026
Merged

Bump AetherEngine to 6.30.1 (partial mitigation for a backward-seek freeze)#89
imbenjamin merged 1 commit into
developfrom
fix/aetherengine-seek-wedge

Conversation

@imbenjamin

Copy link
Copy Markdown
Owner

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 residual comments 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'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. Had to clear DerivedData's cached SPM workspace state (a plain -resolvePackageDependencies reused the stale lock even after deleting the project's own Package.resolved), then regenerated AetherEngineVersion.swift via Scripts/update-aetherengine-version.sh per 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

…-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>
@imbenjamin
imbenjamin merged commit eb18efa into develop Aug 18, 2026
2 checks passed
@imbenjamin
imbenjamin deleted the fix/aetherengine-seek-wedge branch August 18, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant