Defect windows — which bugs were present when

For each fixed defect, the releases it was actually present in. Companion to CHANGELOG.md, which says what changed; this says how long each fault had been shipping before it did.

"Present since" is the first release containing the defective code, not the first release where a user could hit it — those differ, sometimes by months, and the gap is called out where it matters. "How dated" records the evidence, so a row can be re-checked or disputed:

Present since the first release

Nine defects date to the initial proof of concept (v0.0.1, 2026-06-23) and shipped for between two weeks and seven weeks short of two months before anyone hit them. That is the dominant pattern here: not regressions, but original assumptions that went unexercised until a later feature leaned on them.

Why they took so long to surface

Four of these were latent until a later feature exercised them, which is why the fix lands so far from the cause:

• The videoBitrate casing was harmless while every download was original. It became visible only once a quality picker existed to select against — and then produced no error, just a full-size file, because Jellyfin discards an unbound query key silently.
• The unconditional Range header was inert for the same reason: original is the one rung served with a Content-Length and real byte-range support. It started corrupting files in v0.5.1, the moment the casing fix made transcoded downloads actually transcode. So the code dates to v0.0.1 and the corruption to v0.5.1 — a one-release window for the visible symptom.
• The missing PlaySessionId only bites when a stream is re-opened for the same item. Nothing re-opened one until quality switching, transcoded seek and audio-track switching existed.
• The omitted SubtitleStreamIndex only bites on sources whose own default subtitle track is image-based, since that is what forces the server from sidecar to burn-in.

Two were masked by soft failure: the asset protocol being disabled (DR-134) was hidden by the thumbnail cache falling back to the server copy whenever the server was reachable, and AudioStreamIndex=0 was hidden by servers that silently correct an out-of-range index — which is exactly why it was reported as "some videos have no audio" rather than as a bug in the client.

Introduced by a feature, fixed later

Three of these are worth separating out, because the defect is not a mistake in the code so much as plumbing that was built and never connected:

• repository_get_next_up_episodes accepted a series_id from the day it was written, and no caller passed one until v0.3.0.
• The sync queue and its drain were built, tested and running in v0.4.6 with neither of its two would-be producers ever called.
• Both halves of the watched-state backend existed with no caller before v0.5.3.

An automated check cannot see any of these — the code is present, tested and reachable in principle. Only tracing a requirement to a call site catches it.

Short windows (one release or less)

Fixed twice / never actually broken

• Autoplay time reset (v0.0.2). Two commit objects carry this identical change: dcf08f30 (merged via Gitea PR #3, tagged v0.0.2) and fa7cb6e9 (the local original). Both have the same parent 674c8e5c and the same diff. A merge chain pulled fa7cb6e9 and its follow-up 1e599627 into master's history during v0.5.5, so git log v0.5.4..v0.5.5 lists an autoplay fix that changed no file in that release — nextEpisodeService.ts is byte-identical across the tag boundary. The fix shipped in v0.0.2 and has not regressed.

  This is the one case where reading the changelog off git log subjects would have produced a false entry, and it is a good argument for the project's practice of deriving release notes from TRACES rather than commit subjects.

Recurring shapes

Four causes account for most of the table:

1. An omitted parameter is not a neutral default. SubtitleStreamIndex, AudioStreamIndex, GroupItems and MaxAudioChannels all had a server-side default that was actively wrong, and in three of the four the server's choice was more expensive than the one intended — burn-in forcing a full re-encode being the extreme case.
2. Silent binding failures. videoBitRate produced no error, no warning and a plausible-looking file. So did an unbound Range, and so did the coverage gate dividing by a stale denominator.
3. Two layers each assuming the other acts. Native resume (adapter recorded the position, backend never seeked), end-of-playback dispatch (two paths, one unreachable), and the surface/attach split in v0.5.0's native video.
4. A guard keyed on state that moves. The tap deferral keyed suppression on a timer handle the callback had already cleared; the HTML5 toggle keyed play-vs-pause on el.paused, which flips while buffering.

Reproducing this

The pickaxe rows can be re-derived directly:

git log --oneline --reverse -S'<defective token>' -- src-tauri/src   # introducing commit
git tag --contains <sha> | sort -V | head -1                          # first release with it

Blaming the lines a fix removed (git blame at the fix's parent) is faster to run across many commits but was not used for the rows above: it reliably lands on whichever commit last touched the adjacent lines, which is usually not the commit that introduced the defect. It was used only to shortlist candidates.