[UE 5.7.4] World Partition — synchronous ~13s stall a few seconds after Async Loading Screen's StopMovie(), packaged builds only

General Feedback & Requests
,
1

Engine: 5.7.4, Win64, Development build
Context: Migrated a shipped project from 5.2 → 5.7.4. Newly adopted World Partition during this migration. Game worked perfectly in 5.2 (no WP). Migration otherwise successful; this is the one blocking issue.

Symptom:
After the loading screen (Truong Bui’s “Async Loading Screen” plugin) calls StopLoadingScreen() → GetMoviePlayer()->StopMovie(), gameplay begins and an intro video (Electra Media Player, played in a UMG widget) starts. A few seconds into playback (~3-4s), the video freezes for ~13 seconds while its audio (a separate Play Sound 2D node) keeps playing uninterrupted, then the video resumes normally. This only happens in packaged builds — completely fine in PIE/editor.

What’s been ruled out / tried without success:

  • Delaying Stop Loading Screen by any amount (fixed delays, Flush Level Streaming, polling World Partition Subsystem::IsStreamingCompleted) — zero effect on timing, hitch always occurs a fixed-ish interval after StopMovie() regardless of what happens before it.
  • Forcing a synchronous physics scene query (Sphere Overlap) plus a real-time-based watchdog loop timed to hide the stall behind a cover widget — built and verified correct, but didn’t prevent the visible freeze.
  • Enabling the plugin’s native “Wait for PSOPrecaching to Complete” option — the wait exits almost immediately, suggesting either no PSO backlog exists at that check point, or the check runs too early (before WP has streamed in the geometry that will need those PSOs).
  • Confirmed via console (r.PSOPrecaching → returns 1) that PSO precaching is active in this build.

Insights trace evidence (.utrace file attached/linked):

  • Original clean trace: single ~13s block, CPU (GameThread) → TickCompletionEvents → ReleaseTickGroupBlock → TG_EndPhysics → FinishPhysicsSim → EndFrame → CreateExternalAccelerationStructure, with Excl ≈ Incl on CreateExternalAccelerationStructure (i.e., that function’s own code, not children, consumes essentially the whole 13s).
  • Project has heavy ISM/HISM/foliage collision content in the starting World Partition cell (already optimized — simplified collision, split components, density scaling — no further headroom there).
  • Later trace (after adding instrumentation) shows during the same window: GameThread and RHIThread both sitting in WaitForTasks/ProcessUntilTasksComplete (96%+ self-time, i.e. genuinely blocked, not doing nested work), while BackgroundThreadPool #1 is densely, continuously busy for the entire stall duration.
  • A PSO/Encountered new graphics PSO bookmark sits near this window in one capture.

Specific behavioral fact that doesn’t fit a pure “physics catch-up” theory: since the video’s audio (separate system/thread) keeps playing normally throughout the freeze, this doesn’t appear to be a total engine-wide stall — something more specific to the video texture/render update path getting blocked seems to be happening, while general tick/audio continues.

Question: Given the combination of (a) ISM/HISM collision registration bypassing incremental actor registration time-slicing when a WP cell’s level becomes visible (a documented Epic-acknowledged issue), and (b) the RHI-thread-blocked-on-background-pool pattern with a nearby PSO marker — which of these is actually the dominant cost here, and is there a supported way to either force this cost to resolve synchronously before StopMovie() is called (so it can be hidden behind the loading screen), or to have Async Loading Screen/the movie player genuinely hold until it’s resolved, given that our tests of the plugin’s built-in PSO-wait option didn’t catch it?

Happy to share the full .utrace file directly with anyone willing to dig in.