Summary
After focusing into a sub-sequence via double-click on a shot section in a parent sequence’s Shot track, editing a track inside it, then navigating back out, Sequencer’s continuous Play stops advancing the playback clock — both inside the sub-sequence and, once triggered, in the parent sequence as well. IsPlaying() continues to report true and the playback speed/bounds are all normal; the internal time simply never changes on any subsequent tick. Manual scrubbing and direct time-setting continue to work correctly in the same session. The only reliable recovery found so far is reloading the sub-sequence’s package (unreal.EditorLoadingAndSavingUtils.reload_packages()), which is a heavy, destructive-feeling workaround for what looks like a small piece of stuck state.
What Type of Bug are you experiencing?
UI / Tools
Steps to Reproduce
Open the parent Level Sequence in Sequencer.
Double-click a shot section in the Shot track to focus into its sub-sequence (breadcrumb navigation — not opening the sub-sequence asset standalone from the Content Browser).
Edit an animation track inside the sub-sequence (e.g. add/move a key).
Press Play while still focused inside the sub-sequence.
Expected Result
The playhead advances and the animation previews continuously.
Observed Result
The playhead does not move. unreal.LevelSequenceEditorBlueprintLibrary.is_playing() reports True and playback speed reads 1.0, but the current time is frozen. Navigating back up to the parent sequence (via breadcrumbs) and pressing Play there is also frozen — the corruption is not scoped to the sub-sequence’s own focus context, it affects the shared Sequencer instance going forward.
Affects Versions
5.8
Platform(s)
Windows
For crash reports, include your callstack
LevelSequenceEditorBlueprintLibrary.is_playing() → True
LevelSequenceEditorBlueprintLibrary.get_playback_speed() → 1.0
seq.get_playback_start() / get_playback_end() → 0 / 909
(current position ~649, nowhere near either bound)
get_current_time() called 3x, several seconds apart → identical value every call
(rules out a redraw/refresh-only issue — the
internal clock itself is not advancing)
Manual scrubbing / playhead dragging → works normally in this same frozen state
LevelSequenceEditorBlueprintLibrary.refresh_current_level_sequence() → ran without error, no effect
LevelSequenceEditorBlueprintLibrary.force_update() → ran without error, no effect
Additional Notes
Only known workaround: unreal.EditorLoadingAndSavingUtils.reload_packages() on the sub-sequence’s package. This fully resolves playback until the next focus-into/edit/focus-out-of-sub-sequence cycle reproduces it again.
Engineering notes from source inspection (UE 5.8.2) — code-path analysis, not a confirmed root cause, offered in case it saves triage time:
LevelSequenceEditorBlueprintLibrary::IsPlaying() / GetCurrentTime() read directly off the single live FSequencer instance (GetPlaybackStatus() / GetGlobalTime() → PlayPosition.GetCurrentPosition()). There is one FSequencer regardless of focus depth — focusing a shot only pushes/pops ActiveTemplateIDs, it does not open a second editor instance.
Each tick while Playing, FSequencer::Tick() (Sequencer.cpp:1220-1237) computes a new global time from TimeController->RequestCurrentTime(), transforms it to local time via RootToUnwarpedLocalTransform, and calls SetLocalTimeLooped().
SetLocalTimeLooped() (Sequencer.cpp:5621-5760) must invert that transform back to a global time via LocalToRootTransform.TryTransformTime(…). If every inversion attempt fails, it hits an unconditional early return (Sequencer.cpp:5728-5731) before PlayPosition.PlayTo() or EvaluateInternal() are ever called — the only path in the Play tick loop that can leave PlaybackState/PlaybackSpeed fully intact while PlayPosition never advances again on any future tick. This matches the diagnostic trail above exactly.
By contrast, manual scrub / SetGlobalPosition() / SetCurrentTime() route through SetLocalTimeDirectly() (Sequencer.cpp:3712-3727), which inverts the same transform with much more permissive flags (AnyDirection | Cycle | IgnoreClamps) — a plausible explanation for why scrubbing keeps working in the same frozen state.
Ruled out: the inversion above only needs breadcrumb disambiguation when a nested transform is non-linear (MovieSceneSequenceTransform.h:295,450, NeedsBreadcrumb() = !IsLinear()) — i.e. a Time Warp track, Play Rate Curve, or a “Loop” sub-section option present anywhere in the hierarchy. We checked the actual shot sections that reproduce this bug directly in the Section Properties panel: Hierarchical Bias is the default 100 on both shots, Time Scale is Fixed at 1.0 (not curve-based), and Can Loop is unchecked. With a confirmed-linear transform, this code path should not be reachable, so the breadcrumb/non-linear-transform theory is not the cause here.
Since a real Stop→Play cycle, a fresh scrub-then-Play, and a confirmed-linear transform all fail to implicate the transform/breadcrumb layer, the most likely remaining candidate is state that only a package reload rebuilds: the compiled evaluation template / UMovieSceneEntitySystemLinker cached in RootTemplateInstance (driven by CompiledDataManager, Sequencer.cpp:1118-1157). We were not able to inspect that cache’s internal state directly from Python.
Clock source confirmed not using a non-default EUpdateClockSource (Platform/Audio/Timecode) — ruled out as unrelated to a separate 5.8-only packaged-build regression path (Sequencer.AllowPausedClock).
No UE-XXXXX ticket references or comments describing this behavior were found in the Sequencer or MovieScene runtime source for this build.
Impact
Breaks the normal “double-click shot → edit → preview” cinematics workflow. Requires reloading packages to recover, which is disruptive mid-session (loses undo history for that sub-sequence, risks discarding unsaved work if not careful) and easy to not realize is necessary, since Sequencer gives no indication that Play silently stopped doing anything.