Bug Report: Clip-level freeze during timeline editing (likely race condition in preview/cache generation)

Note on how this report was compiled: This report was written by Claude (Anthropic's AI assistant) after an extended, iterative troubleshooting session conducted directly with the affected user over two days. Claude proposed and walked the user through the large majority of the diagnostic steps and hypotheses listed below — including the many that turned out to be dead ends — reviewed the Task Manager, MediaInfo, and CrystalDiskMark evidence the user captured at each step, and drafted this write-up based on that full process. The user also crowd-sourced several additional testing ideas from a Reddit thread, which are folded into the "Ruled Out" section with credit implied to that community input. The conclusions below represent the most-supported working theory given everything tested, not a confirmed root cause from Adobe's internal code — only Adobe engineers can confirm the actual mechanism.

Summary

While editing a large "rough cut" timeline (multiple hours of source footage cut down toward a short final edit using ripple trim), Premiere Pro repeatedly freezes at the individual clip level. The application itself remains responsive — menus, playhead movement, and sequence-structure edits (cuts) continue to work — but the selected clip stops responding to anything (no Effects Controls update, no color/effect changes). CPU, GPU, and disk usage all drop to near-zero during the freeze rather than spiking. The issue has been reproduced across multiple Premiere versions, GPU configurations, audio configurations, and source media types, and appears to originate inside Premiere's own preview/cache generation system rather than from any external/environmental cause.

Environment

• OS: Windows 11
• Premiere Pro versions tested (issue present in all): 26.8.1, 26.5, 26.0.2, 25.5
• CPU: Intel Core i7-12700K
• GPU: AMD Radeon RX 9070 XT — Adrenalin driver 26.8.1 (build 32.0.31041.1004), OpenCL 2.1 confirmed active
• iGPU: Intel UHD Graphics (integrated) — tested both enabled and fully disabled in Device Manager
• RAM: 32 GB
• Monitor: 3440x1440 @144Hz, VRR/FreeSync enabled
• Storage: Samsung 980 PRO NVMe SSD — holds project file, media, media cache, and proxies. Benchmarked with CrystalDiskMark at ~6855 MB/s sequential read, matching rated spec (i.e., drive itself is healthy)
• Audio hardware/software: Behringer UMC audio interface (driver v2.29.0), Elgato Wave Link, VB-Audio Virtual Cable — tested both fully active and fully disabled at the Windows device level

Source Media

• Source A: iPhone-recorded MP4, H.264, 1920x1080, 30fps
• Source B: OBS-recorded MP4, H.264, 1920x1080, 60fps
• Both confirmed Constant Frame Rate via MediaInfo (tree/text view), not VFR
• Also tested and reproduced the issue with: untranscoded RAW originals of both sources, HandBrake H.264 re-encodes, HandBrake ProRes 422 LT re-encodes, and Premiere-generated proxies of each — the issue is not specific to any one codec, container, or transcoding tool

Steps to Reproduce

1. Import several hours of raw source footage (mixed 30fps and 60fps sources in this case) into a single sequence.
2. Begin a rough cut using ripple trim (Q/W) to cut the sequence down toward a much shorter final duration.
3. Continue cutting, zooming, and scrubbing/playing back over an extended session (30+ minutes).
4. Freezes begin occurring, initially minutes apart, progressively shortening in interval over the session (down to as little as 10-15 seconds between freezes). Restarting Premiere or clearing the Media Cache resets the interval temporarily, but the shortening trend resumes.

Actual Result

• The freeze is not a full Windows "Not Responding" hang. Premiere continues to respond to window focus, menu clicks, and dialogs.
• Sequence-level operations (moving the playhead, making new cuts to the edit structure) continue to work during a freeze.
• Clip-level operations stop responding entirely on the affected clip: Effects Controls panel will not update, color/effects cannot be changed, playback of that clip does not advance.
• CPU and GPU usage drop to ~0% during the freeze (confirmed repeatedly via Task Manager) — no spike, and no rise in temperature.
• Disk activity also drops to near-zero (~0-1% active time, low KB/s to low MB/s) during a freeze, measured against a drive independently benchmarked at ~6800 MB/s sequential read — nowhere near saturated.
• Windows' built-in "Analyze Wait Chain" tool reports Premiere Pro.exe as "running normally" during a freeze, ruling out a classic OS-level deadlock (mutex/handle wait).
• The freeze can sometimes be interrupted manually by: zooming the timeline out to fit the entire sequence and pressing Play; zooming in/out specifically on the audio waveform display. (Alt-tabbing away and back also worked earlier in testing but became unreliable later.)

Expected Result

Editing operations (cutting, zooming, scrubbing, adding transitions/effects) should not cause the application or individual clips to become unresponsive, regardless of session length or accumulated cache size.

What Reliably Triggers a Freeze

Any action that requires Premiere to generate a new preview/cache asset for a clip/region it has not already cached at that specific state:

• Zooming into a timeline region for the first time, forcing new video thumbnail generation (especially where several short clips become visible at once)
• Audio waveform generation/redraw for a region not yet cached
• Adding a transition (freezing resumes after roughly 4-5 transitions added in a session)
• Applying an audio effect (as opposed to a plain volume/gain keyframe, which is safe — see below)
• Marking a new In/Out point on a previously untouched section and running Sequence > Render Effects In to Out, even when there is nothing that actually needs rendering

What Does NOT Trigger a Freeze

• Moving/repositioning clips that are already rendered/cached
• Playing back sections already viewed at the current zoom level (thumbnails already cached)
• Adjusting clip volume via keyframes without an audio effect applied
• Playing back a section that has already been fully pre-rendered (green work-area-bar)

Ruled Out (with supporting evidence)

• GPU driver issue: Confirmed OpenCL 2.1 active and functioning on the installed AMD driver (26.8.1); not the separate AMD OpenCL-removal regression some users reported on a different driver branch (26.5.1+).
• General Premiere version regression: Issue reproduces identically on 26.8.1, 26.5, 26.0.2, and 25.5.
• GPU driver TDR (Timeout Detection and Recovery): A TDR self-resolves without user input; this issue requires manual intervention and does not self-resolve. Event Viewer showed no conclusive TDR events at freeze times.
• Hardware-Accelerated GPU Scheduling (HAGS): Disabled and retested — no change. Later re-enabled along with everything else and reproduced identically.
• Cloud sync interference: Project file and media cache confirmed to reside on the local NVMe drive, not inside any cloud-synced folder (Google Drive/OneDrive/Dropbox).
• Project file corruption: A brand-new project built from scratch with the same source media reproduces the same degrading pattern.
• Variable Frame Rate (VFR) media: Confirmed Constant Frame Rate via MediaInfo on both source files as actually used in the edit (post-transcode).
• Source codec/container/transcoding tool: Reproduces identically across untranscoded RAW originals, HandBrake H.264, HandBrake ProRes 422 LT, and Premiere proxies. Since untranscoded RAW footage alone already reproduces the issue, no transcoder or intermediate codec choice can be the cause.
• SSD/media cache I/O bottleneck: Drive benchmarks at rated speed; disk activity measured near-zero during an active freeze.
• Thermal throttling / failing hardware: CPU/GPU temperatures remain normal throughout, including in extended sessions.
• Audio interface / virtual audio routing (Behringer UMC, Elgato Wave Link, VB-Audio Virtual Cable): Fully disabled at the Windows device level and retested — issue reproduced identically. Later re-enabled everything and reproduced identically again.
• Intel integrated GPU running alongside the discrete GPU: Disabled in Device Manager and retested — issue reproduced identically.
• "Media Intelligence Analysis" (Preferences > Media Analysis & Transcription): Disabled — no change.
• Automatic audio waveform/peak file generation: Disabled in Preferences > Audio, and existing peak files purged from AppData\Roaming\Adobe\Common — no permanent change; freeze still occurs once new waveforms need generating during active editing.
• Media Cache state: Cleaning it provides only brief (~5 minute) temporary relief before the degrading pattern resumes.
• Timeline video thumbnails: Disabling them does not change time-to-freeze; it only removes one of the manual "unstick" methods (zoom-to-fit).
• GPU rendering path (Mercury Playback Engine Software Only): Could not be isolated as a variable — Adobe removed this option from the Renderer dropdown starting in version 25.2, and the Shift-launch one-time software-rendering override is also no longer available in the tested version (26.0.2), so a GPU-off comparison is not currently possible on this setup.

Working Hypothesis

The evidence points away from all external factors (hardware, drivers, OS settings, media files, audio devices, cloud sync) and toward an internal concurrency issue inside Premiere's own preview/cache-generation engine. The pattern is consistent with a race condition between a background thread writing a new cache asset (thumbnail, waveform, effect/transition preview) and the foreground UI/playback thread trying to read that same asset — where, under some condition that becomes more likely as more cache entries accumulate during a session, one side waits indefinitely instead of the operation completing or timing out. This would account for:

• CPU/GPU/disk all dropping to near-zero during the freeze (a thread blocked on a lock does not consume resources)
• The freeze being scoped to the specific clip/asset rather than the whole application or sequence
• The issue worsening the longer an editing session runs (more cache writes = more opportunities for the race condition)
• Reproducibility across every tested media type, codec, GPU configuration, and audio configuration, since none of those are the actual point of failure