camkit rebuild: 3+ fragments from one screen recording hangs Camtasia on open

[RichardBray]

Summary

camkit rebuild can produce a project.tscproj that permanently hangs Camtasia on open (CPU pegged 600-750%, unresponsive, system-wide lag, never self-resolves after 2+ min, requires force-quit) when a single screen-recording source (ScreenVMFile + paired UnifiedMedia camera track) is cut into 3 or more separate timeline fragments.

Repro

Confirmed on fc-loop.cmproj (Camtasia build 2026.1.3) via isolated scratch-copy testing:

1. Take a project with a screen+camera recording source (dual-track: ScreenVMFile on one track, UnifiedMedia on a paired track, same src id, matching start/duration).
2. Run camkit rebuild --from <keep.json> --force with a keep-list that references that source 3+ times (3+ separate {start,end} ranges from the same src).
3. camkit open (or manually opening the resulting .cmproj) hangs Camtasia indefinitely.

Isolation results

• 1 fragment from a screen source: opens fine, low CPU.
• 2 fragments from the same screen source: opens fine.
• 3 fragments from the same screen source: hangs, reproducibly. Confirmed independent of whether Camtasia was already warm/idle or freshly launched — not a startup race.
• Plain webcam-only (UnifiedMedia, no screen capture) sources cut into many fragments: no problem, even many cuts.
• The resulting project.tscproj was verified valid: correct JSON, sane sourceBin/track/media counts, matching start/duration between the two tracks of a screen+camera pair, no negative/zero-duration clips, no group/link fields present or malformed in the schema.
• packages/core/src/rebuild.ts is unchanged between main and the live-timeline-editing branch (verified via git diff main...HEAD), so this is not a branch-specific regression — main should reproduce identically.

Hypothesis (unconfirmed)

Camtasia is a closed binary so the internal mechanism isn't directly inspectable. Best guess: something Camtasia recomputes per screen-recording fragment on load — likely SmartFocus/cursor-tracking data or thumbnail/waveform proxy generation (each clip's parameters includes cursorTrackLevel, cursorScale, geometryCrop0-3, etc.) — that's cheap for 1-2 fragments but becomes pathological (infinite loop or exponential blowup) at 3+.

Impact

Blocks the rough-cut skill (skills/rough-cut/SKILL.md) for any screen-recording-heavy project, since a real rough cut typically needs many more than 2 cuts inside a single screen recording.

Next steps to investigate

• Diff a working 2-fragment project.tscproj against a hanging 3-fragment one field-by-field for anything that changes qualitatively (not just count).
• Sample the hung Camtasia process's stack (Activity Monitor "Sample Process") to see what function it's actually spinning in.
• Try merging adjacent kept fragments within a screen source below some gap threshold in rebuild.ts so each screen source ends up with only 1-2 pieces instead of many, as a workaround pending a real fix.

[RichardBray]

Root cause found: it's timeline-cell thumbnail decode of the tscc2 screen codec, NOT SmartFocus

Investigated on a scratch APFS-clone of fc-loop.cmproj (build 2026.1.3). Reproduced the hang cleanly with a minimal 3-fragment keep-list from one ScreenVMFile source (src4): CPU pegged 715-751%, never resolves, force-quit required.

The SmartFocus / cursor hypothesis is disproved

Neutralizing cursorTrackLevel (1000 → 0) on every rebuilt ScreenVMFile fragment made no difference - the 3-fragment project still pegged at ~720% and hung. So cursorTrackLevel / smoothCursorAcrossEditDuration are not the trigger.

What it actually is

Backgrounded a sample of the hung process (had to write to a file - the box is too slowed to keep sample in the foreground). The dominant stack:

-[EditorWindowController initUIWithProject:document:viewData:changeAllKeyFrames:]
  -[_NSCollectionViewCore _createPreparedCellForItemAtIndexPath:...]
    -[MediaDescriptor imageForTrecWithPath:atTime:]
      +[NSImage(MediaThumbnails) imageForPath:andTrack:andOrientation:asPip:atTime:]
        -[AVAssetReaderTrackOutput copyNextSampleBuffer]   (AVFCore)

So on project open, EditorWindowController builds the timeline UI, and for each timeline clip cell it generates a poster thumbnail by decoding a video frame from the .trec at that clip's mediaStart offset (imageForTrecWithPath:atTime: → copyNextSampleBuffer). This runs during synchronous window/UI init.

Why screen sources specifically, and why 3+

• The .trec video stream is tscc2 (TechSmith Screen Codec 2) - software-decoded, no hardware acceleration. ffprobe: codec_name=tscc2, 60fps, 8459 frames, 999.8s. Every thumbnail frame is a CPU-bound software decode.
• Webcam-only (UnifiedMedia) sources are H.264 - hardware-decoded, cheap - which is exactly why cutting them into many fragments has always been fine.
• More fragments = more per-cell tscc2 thumbnail decodes fired during UI init. 1-2 stays tolerable; at 3+ the aggregate work (parallelized across cores → 700%+) overwhelms init and it never converges.

Corrected impact

Not a schema-validity or SmartFocus issue at all - it's Camtasia's own thumbnail pipeline choking on repeated tscc2 decodes. The rebuilt project.tscproj is valid; Camtasia just can't build its timeline UI for it.

Next steps to try

• Look for a schema field that supplies/caches a per-clip poster image or disables cell thumbnails, so Camtasia doesn't decode tscc2 on init.
• Test the merge-adjacent-fragments workaround (≤2 pieces per screen source) - fewer cells, fewer decodes - but it re-swallows mid-source dead air, so it's a stopgap.
• Check whether referencing the screen media as a plain video type (not ScreenVMFile) avoids the imageForTrec path.

[RichardBray]

Correction: it's the CAMERA (UnifiedMedia) track thumbnail, and "3+ fragments" is NOT the trigger

Further testing overturns both my previous comment and the original repro. Findings below are all verified on isolated APFS-clone .cmproj bundles (fresh open each time, stale ~project.tscproj lock removed), watching ps CPU.

"3+ screen fragments hangs" is falsified

Another Claude-cut project, last30days.cmproj, has screen+camera sources cut into 17 / 17 / 25 fragments and opens fine (CPU spikes to ~280% then settles to idle in ~15s). So fragment count is not the trigger. Confirmed by cloning last30days and opening it: clean.

The hang is the camera track, not the screen track

Minimal fc-loop repro (one screen+camera source, 3 fragments), then delete one track before opening:

• Screen-only (keep the 3 ScreenVMFile clips, drop the UnifiedMedia camera clips): opens clean, idle in 15s.
• Camera-only (keep the 3 UnifiedMedia clips, drop the ScreenVMFile clips): hangs at ~700%, never resolves.

So Camtasia's thumbnail loader chokes on the camera track (UnifiedMedia) of a fragmented screen+camera .trec, not the screen capture. Even a 134s source cut 5 ways hangs - it is not about duration either.

Confirmed hot path (unchanged)

EditorWindowController initUIWithProject:...changeAllKeyFrames:
  _NSCollectionViewCore _createPreparedCellForItemAtIndexPath:
    CamtasiaMediaLib::DebouncingThumbnailLoader::loadThumbnailForMedia(...)
      MediaDescriptor imageForTrecWithPath:atTime:
        NSImage(MediaThumbnails) imageForPath:andTrack:andOrientation:asPip:atTime:
          AVAssetReaderTrackOutput copyNextSampleBuffer   (AVFCore)

Poster-thumbnail decode per timeline clip cell, via AVAssetReader, for the camera track (asPip).

Ruled out with measurements (fc-loop-hangs vs last30days-works)

Variable	fc-loop (hangs)	last30days (works)	verdict
camera fragments	3+	up to ~12/track	count not causal
screen codec	tscc2	tscc2	identical
resolution / fps	3360x2100 / 60	same	identical
source duration	134-1000s	396-560s	not causal (134s hangs)
camera h264	High/L4.0, yuv420p, 2 B-frames, ~29fps VFR, ~10.5Mbps, ~1 keyframe/s	near-identical	not obviously causal
ffmpeg decode speed (screen + camera)	fast (~0.3s/60s screen, ~2.6s/60s cam, seek <1s)	same	decode cost not causal
clip + sourceBin schema	identical	identical	not causal

Still open: the actual trigger

Why fc-loop's camera-track thumbnails spin forever while last30days's near-identical ones don't is not yet isolated. Prime suspect: AVFoundation-specific AVAssetReader ... atTime frame extraction on the VFR / B-frame camera stream inside the multi-stream .trec - ffmpeg decodes both files fine, but Camtasia uses AVFoundation, which can loop/stall differently on VFR seeking. Next step is an AVFoundation-based (not ffmpeg) per-frame extraction probe against both .trec camera streams at the exact fragment offsets to see which stalls.

Workaround implication

Since screen-only opens fine, the blocker is specifically the camera thumbnails. A fix will likely need to either suppress/cache the UnifiedMedia camera-clip thumbnails on rebuild, or normalize/re-encode the camera stream, rather than merging screen fragments.

[RichardBray]

Isolated to the CAMERA (UnifiedMedia) clip of a screen .trec - but origin still not fully settled

Confirmed by track-bisecting the minimal fc-loop repro (clones, fresh open, watching CPU)

Take one fc-loop screen+camera source cut into 3 fragments, then delete one track before opening:

• Screen-only (keep the 3 ScreenVMFile clips): opens clean, idle in ~15s.
• Camera-only (keep the 3 UnifiedMedia clips): pegs ~700%, never resolves.

So the hang is the camera-track (UnifiedMedia) thumbnail, not the screen capture.

The camera clips that hang reference a screen .trec

In fc-loop, src4-7 are ScreenVMFile + UnifiedMedia pairs - a webcam PIP composited over each screen recording. The UnifiedMedia clip points at the same multi-stream screen .trec (3360x2100 tscc2 screen stream + 1920x1080 h264 camera + aac). Note the contrast within fc-loop itself: src2/src3 are also UnifiedMedia-only, but they point at pure-webcam .trecs (intro/exp) and fragment fine. Only the UnifiedMedia clips that reference a screen .trec hang. Hypothesis: thumbnailing that camera clip forces Camtasia to open/index the whole multi-stream file (incl. the large tscc2 screen stream) per fragment.

Raw decode is NOT the cause

Wrote an AVFoundation probe (AVAssetReaderTrackOutput, camera track, timeRange starting at the fragment offset - the same class shown in the hung stack). Both the working and hanging .trec camera streams return the first decoded frame in ~0.14-0.29s at every offset (7s..440s). ffmpeg decodes both fast too. So it is not decode/seek cost at the codec level - the hang is above the decoder, in Camtasia's thumbnail pipeline (CamtasiaMediaLib::DebouncingThumbnailLoader → imageForTrecWithPath:atTime: → imageForPath:andTrack:andOrientation:asPip:atTime:).

Open caveat (do not treat "screen-only vs paired" as settled root cause)

The comparison project last30days.cmproj (which opens fine at 17-25 fragments/screen source) currently has its screen sources as ScreenVMFile-only - no UnifiedMedia camera pair - which matches the "screen-only opens" bisect. BUT the project owner reports last30days was originally the same paired screen+camera format as fc-loop. Its project.tscproj.bak is gone, so this can't be verified from disk. If true, the camera pairs were dropped somewhere downstream, and "having a camera-over-screen pair" may be a symptom rather than the true trigger. Needs a project that is confirmed paired-at-origin and opens fine (or confirmed paired and hangs) to close this.

Ruled out with measurements (recap)

Fragment count (last30days has more, opens), screen codec (both tscc2), resolution/fps (identical), source duration (a 134s fc-loop source still hangs), camera h264 params (near-identical: High/L4.0, yuv420p, 2 B-frames, ~29fps VFR, ~10.5Mbps, ~1 keyframe/s), raw AVFoundation + ffmpeg decode speed (fast for both), clip + sourceBin schema (identical).

Practical note

Owner is editing fc-loop manually for now. A programmatic fix likely needs to suppress/cache thumbnails for UnifiedMedia clips that reference a screen .trec, rather than limiting fragment count or touching the screen track.

[RichardBray]

Hit this again today rough-cutting a real project (pagination.cmproj, 6 sources, 3 of them ScreenVMFile + paired UnifiedMedia camera track). New data point:

Fragment-count threshold confirmed on a second, unrelated project. A cut with src5 (screen) at 9 fragments and src6 (screen) at 10 fragments hung Camtasia on open — CPU pegged, force-quit required after ~1 min. Force-quit was safe; the written project.tscproj itself was unaffected (verified structurally sound), and restoring from project.tscproj.bak recovered the pre-rebuild project fine. No corruption, purely an open-time hang.

Workaround tried: merge down to ≤2 fragments per screen source. This does avoid the hang (confirmed — opened fine at 2 fragments each), but the workaround is a much bigger trade-off than the issue's "next steps" implied. The retakes in a real recording aren't clustered near a few points — they're scattered as many small islands across the whole file (this session's src6 had a clean take, then 8 separate retake-inflated gaps of various sizes throughout the full 373s file). Merging to 2 fragments means picking the single largest gap as the one allowed split point and swallowing every other gap's raw content back into the kept range. Concretely, src6 went from a 10-fragment cut (~30s total kept, well-trimmed) to a 2-fragment cut where one fragment alone is 340s and still contains most of the stumbling/false-starts I was trying to remove. So the workaround is not "merge a few adjacent small gaps," it's "abandon fine-grained cutting entirely for any screen source with distributed retakes" — which is most real screen-recording rough cuts, undermining the point of rough-cut for exactly the material it exists to help with.

This makes the fragment-count cap effectively load-bearing for the whole rough-cut skill, not an edge case — worth bumping priority.

Also want to flag an alternative workaround for whoever picks this up, since brute-force merging isn't really viable: split the underlying screen .trec into N physical sub-files (e.g. via ffmpeg -ss/-t) at the fragment boundaries, add each as its own media-bin source, and reference each with ≤2 fragments. That preserves fine-grained cutting while staying under whatever Camtasia's per-source limit is — more moving parts (new bin sources, sourceBin XML), but doesn't force the "keep only 2 fragments" trade-off. Didn't attempt it this session (ran out of budget), but it seems like the more durable fix path if the root cause (SmartFocus/cursor-tracking recompute, per your hypothesis) turns out to be hard to actually fix upstream.

[RichardBray]

Found a real lead by comparing against a manually-edited project rather than another rebuild.

Setup: took the same project from my earlier comment, restored to the pre-rebuild backup, and this time cut it by hand inside Camtasia's own timeline UI (many incremental splits) instead of via camkit rebuild. Result: src6 ended up at 19 fragments, src5 at 13 — both far past the "3+" threshold — and it opens/plays fine, no hang, no elevated CPU.

Then diffed clip JSON structure. Reconstructed a camkit rebuild with a 10-fragment cut on src6 in a scratch copy (same source, same project, same parameters template) and compared one resulting clip against the equivalent hand-split clip from the working file. They're structurally identical: same fields, same shape (parameters.*.defaultValue scalars, empty animationTracks: {}), only id/start/mediaStart/mediaDuration differ, which is expected and correct. No cursorTrackLevel/geometryCrop/keyframe-array divergence — the original hypothesis in this issue doesn't hold up under this comparison. The clips camkit produces are not structurally different from clips Camtasia produces itself.

Revised hypothesis: it's not fragment count, it's fragment provenance — specifically, batch-introducing many brand-new (never-before-seen) ranges from one screen-recording source in a single file-open event. Hand-splitting in the UI introduces one new range at a time, each adjacent to material Camtasia has already analyzed/cached (cursor tracking, SmartFocus, thumbnails/waveform proxies) — so there's never more than one new computation pending. A camkit rebuild (or presumably any external tool, or a paste of many clips at once) hands Camtasia N simultaneous novel ranges from the same source on load, which is the scenario that seems to hang. This would explain why the fragment count itself isn't structurally different but something in Camtasia's load-time analysis path chokes specifically on the "many-at-once" case.

Suggested next step for whoever picks this up: test whether the hang reproduces from a pasted multi-clip edit done entirely within Camtasia (select N ranges, split all at once, save, reopen) vs one done via sequential single splits — if the pasted/batch case also hangs even without any external tool involved, that would confirm this is about batch-vs-incremental analysis scheduling rather than anything specific to camkit's output format, and the real fix (if any) would need to happen on Camtasia's side or by warming the cache incrementally from camkit before rebuild (e.g. open the project after each single cut, let Camtasia settle, then apply the next) rather than trying to alter the tscproj JSON shape.

[RichardBray]

Root cause confirmed via process sampling on a hung open (Camtasia 2026.1.4, macOS 26.5.2), on an unrelated hand-edited project (parse.cmproj) that hit the identical symptom.

Main-thread stack during hang

sample of the hung process shows the main thread blocked 100% of samples in timeline thumbnail generation:

-[MediaDescriptor image]
-[MediaDescriptor onlineImage]
-[MediaDescriptor imageForTrecWithPath:atTime:]
+[NSImage(MediaThumbnails) imageForPath:andTrack:andOrientation:asPip:atTime:]
CPRMovieImageExtractor_impl::firstVisibleImageAtOrAfterTime
CSRenderLib::VideoFileFrameGrabber::frameAtTime
CodecLib::AVFVideoSampleReader::readVideoSample
  -> rebuildSampleReaderAndGrabFrameAtTime
-[AVAssetReaderTrackOutput copyNextSampleBuffer]   <- never returns
FigSemaphoreWaitRelative / WaitOnCondition (CoreMedia)
__psynch_cvwait

So the hypothesis in the issue body is right, and it's specifically the thumbnail/proxy path: the main thread synchronously waits on an AVFoundation copyNextSampleBuffer that never completes - a deadlock, not an infinite compute loop (CPU spin is other threads; the main thread is parked on a condition variable forever).

Bisection results (fresh minimal projects, one variable at a time)

Project	Result
1 clip from a .trec	opens
2 clips from same .trec	opens
4+ clips from same .trec	hangs, reproducibly
Same clips, all effects stripped	still hangs (effects innocent)
Nonzero mediaStart single clip	opens
UnifiedMedia removed	still hangs

Threshold matches the 3+ fragments reported here. One correction to the issue body: it is not limited to screen (ScreenVMFile/tscc2) sources - plain h264 camera-only .trec clips (VMFile+AMFile) deadlock exactly the same way at 3+ fragments. The earlier "webcam-only sources with many cuts are fine" observation was almost certainly a thumbnail cache effect: projects whose thumbnails were generated under an older build keep opening fine, while any project needing fresh thumbnails for 3+ fragments of one trec deadlocks. That also explains "old projects open, new ones hang" without any file-level difference (verified: byte-level container/codec parameters of old vs new trecs are identical).

Trec files are healthy

All trecs ffprobe clean. AVFoundation reads the h264 tracks fine out-of-process (the tscc2 screen track fails fast with Cannot Decode -11833, as expected - Camtasia supplies that decoder). The deadlock is in Camtasia's in-process concurrent use of AVAssetReader across multiple thumbnail requests against the same file.

Workarounds validated

1. Keep any rebuild output to max 2 fragments per trec source (the merge-adjacent-fragments idea in "Next steps" is the right call for rebuild.ts).
2. Re-mediate to mp4/mov: extract streams via ffmpeg (camera h264 = -c copy remux; tscc2 screen = re-encode) and point sourceBin at the mp4s. A rebuilt .cmproj with identical timeline over mp4 sources opens instantly with unlimited fragments - mp4 thumbnailing doesn't hit the trec-specific imageForTrecWithPath path.

Full sample outputs available; worth attaching to a TechSmith bug report.

[RichardBray]

Second workaround confirmed by hands-on test: Camtasia's built-in Create Proxy Video works on .trec sources (it does build an .ief proxy in ~/Library/Application Support/TechSmith/Camtasia/MediaProxies/, keyed name_size.ief, despite never doing so automatically for trecs). With the proxy fully built, a project with 6 cuts from a single .trec saved, closed, and reopened cleanly - well past the 3-fragment deadlock threshold. Caveats: proxy creation is manual per clip, must complete before save/close, proxies are large (1.1GB for a 365MB trec), and deleting the proxy re-exposes the deadlock on next open. mp4 re-mediation remains the robust fix; proxies are a viable in-app workaround.

[RichardBray]

Correction on the proxy workaround: it is NOT reliable. A 24-cut project hung on open even with the .ief proxy fully built (same key, verified present). sample shows the identical AVAssetReader deadlock, this time triggered from the media-bin thumbnail (AssetBinMediaController → imageForTrecWithPath: → copyNextSampleBuffer never returns) - thumbnail generation reads the .trec directly even when a proxy exists. The 6-cut proxy success was apparently just winning the race. Also re-confirmed the bug is unfixed in Camtasia 2026.1.4 (released today). Only reliable workaround: convert trecs to mp4 before editing.