[helgehoi]

Ticket

VI-5068 — [tamstool] Upgrade TAMS Store Browser to TAMS 8.2

The bug

In /#/embed, a source that is currently ingesting shows the LIVE badge but no Open button, so a live recording cannot be sent to CuttingRoom from the embed at all.

Why

The button was gated on a computed duration:

{source.durationMs > 0 && <button className="embed-open-btn" …>Open</button>}

and durationMs is only ever set when both bounds of the flow's timerange are known:

const parsed = parseTimerange(tr);
if (parsed.start !== null && parsed.end !== null) {
  durationMs = Number((parsed.end - parsed.start) / NANOS_PER_MS);
}

A growing flow reports an open-ended timerange ([start_), which parses to end: null. So durationMs stays null no matter how many segments have landed, and the button never renders. The LIVE badge sits on a different condition (detailsLoaded && isGrowing), which is why the row lights up but has nothing to click.

The gate came from 530b49a — "Hide Open button until flow has at least one segment… the asset would otherwise resolve to an empty flow." The intent is right; duration was the wrong proxy for it, and it only ever held for closed flows.

Worth noting handleOpen already anticipates this case — it posts status: source.isGrowing ? "growing" : "ready" to the parent — so opening a live source is a supported path the UI was hiding.

The fix

Gate on the segments themselves. New timerangeHasMedia in src/utils/timerange.js reads the bounds from the timerange string rather than from parseTimerange, for the same reason isInitSegmentEntry does: parseTimerange collapses "empty", "inverted" and "did not parse" onto the same 0n..0n result, so trusting it would treat a corrupt timerange as openable.

timerange	timerangeHasMedia	before (durationMs > 0)
[1750000000:0_1750000060:0) — closed	✅	✅
[1750000000:0_ — growing	✅	❌ ← the bug
_1750000060:0) — open start	✅	❌
[1750000000:0_1750000000:0) — zero length	❌	❌
() / [] — empty	❌	❌
1750000000:0 — bare timestamp	❌	❌
nonsense / absent	❌	❌

A flow with no segments yet still stays unopenable, which is what 530b49a was protecting.

Testing

• npm run build passes (Node 22, same as CI)
• Executable assertions over timerangeHasMedia against the real TIMERANGE_REGEX and EMPTY_PATTERNS — all 13 cases in the table above, plus null/undefined/"", confirming the growing case flips from hidden to shown and nothing else changes
• npm run lint still cannot run in this repo (ESLint 9 needs a flat config, deliberately left out of VI-5068 Support TAMS 8.2 in the TAMS Store Browser #20) — the build is the gate

Not verified against a live 8.2 store — I have no ingesting endpoint to point at, so the live path is exercised by the timerange logic rather than end to end. The failing gate is unambiguous in code, but the shape a given store reports for a growing flow is worth a look on first use.

🤖 Generated with Claude Code