chore(release): v0.12.2

Two download fixes since v0.12.1: transfers longer than five minutes were
being cut off by a total request deadline and restarted from zero, and the
progress bar read "0%" for the whole of a transcode download.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -9,6 +9,39 @@ generated trace matrix lives in [docs/traceability.md](docs/traceability.md).
 For how long each fixed defect had been shipping before it was found, see
 [docs/defect-windows.md](docs/defect-windows.md).
 
+## v0.12.2
+
+Two download fixes, found together on a tablet whose films all needed their
+audio re-encoded. Downloads that took longer than five minutes were being cut
+off and restarted, and the progress bar sat on "0%" for the whole of a
+transcode.
+
+### 🐛 Fixes
+
+- **Downloads longer than five minutes no longer fail.** The download worker's
+  HTTP client carried a *total* request deadline of five minutes — from
+  connect until the last byte — so every transfer longer than that was cut off
+  mid-body and retried. A transcode cannot be resumed (the server ignores
+  `Range` and starts over), so each retry threw away what had been fetched, hit
+  the same deadline, and after three attempts the download failed. No feature
+  film at transcode speed could complete; a large direct copy limped through in
+  five-minute slices with a backoff between each. The deadline is now a
+  30-second connect timeout plus a 60-second *stall* timeout that resets on
+  every chunk: a dead connection is still caught, a healthy transfer can run as
+  long as it needs. Present since the first release. (DR-289)
+
+### ✨ Improvements
+
+- **The progress bar moves during a transcode download.** A transcode is
+  produced as it is sent, with no `Content-Length`, and the bar had nothing to
+  measure against — it read "0%" until the file completed. The backend now
+  predicts the size when it resolves the download: the source's size for
+  `original` (the picture is copied byte-for-byte; only the audio changes), or
+  bitrate × runtime for a quality preset. The bar shows the estimate as
+  "~42%" and caps at 99% until the last byte lands; the server's own figure is
+  used whenever it gives one; and when there is no prediction at all the bar
+  is a moving band with the bytes so far, rather than a false "0%". (DR-290)
+
 ## v0.12.1
 
 One change: the TLS library every connection to the server goes through has a

docs/defect-windows.md

@@ -17,8 +17,8 @@ row can be re-checked or disputed:
 
 ## Present since the first release
 
-Sixteen defects date to the initial proof of concept (v0.0.1, 2026-06-23) and
-shipped for between two weeks and two months before anyone hit them.
+Eighteen defects date to the initial proof of concept (v0.0.1, 2026-06-23) and
+shipped for between two weeks and three 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.
 
@@ -47,6 +47,14 @@ for ~2.
 | Audio-track change asked the player to select a track the transcode never carried (DR-258) | v0.0.1 | **v0.11.1** | ~2 months | pickaxe |
 | Subtitle URL missing its `Stream.` route segment, so every fetch 404ed (DR-259) | v0.0.1 | **v0.11.1** | ~2 months | pickaxe |
 | `timeupdate` gated on `!isPlaying`, so a paused activity froze the position (DR-265) | v0.0.1 | **v0.11.5** | ~9 weeks | pickaxe |
+| Download client used a 5-minute *total* request deadline, so any transfer longer than that was cut off and retried (DR-289) | v0.0.1 | **v0.12.2** | ~13 weeks | pickaxe |
+| Progress reported 0.0 for any response without `Content-Length` — every transcode download (DR-290) | v0.0.1 | **v0.12.2** | ~13 weeks | absence |
+
+The two v0.12.2 rows are the same latent shape as the `Range` header above:
+the deadline was inert while every download was a short direct copy, and
+became fatal only once DR-171 (v0.5.3) started re-encoding audio for offline
+playback — a transcode is both slow enough to exceed five minutes and
+impossible to resume. Defective for ~13 weeks, hittable for ~5.
 
 ### Why they took so long to surface
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "jellytau",
-  "version": "0.12.1",
+  "version": "0.12.2",
   "description": "A cross-platform Jellyfin client built with Tauri, SvelteKit and Rust.",
   "author": "Duncan Tourolle <duncan@tourolle.paris>",
   "license": "MIT",

src-tauri/Cargo.lock

@@ -2275,7 +2275,7 @@ dependencies = [
 
 [[package]]
 name = "jellytau"
-version = "0.12.1"
+version = "0.12.2"
 dependencies = [
  "aes-gcm",
  "argon2",

src-tauri/Cargo.toml

@@ -4,7 +4,7 @@ name = "jellytau"
 # `player-conformance`, and a second binary makes a bare `cargo run` —
 # which `tauri dev` issues — ambiguous.
 default-run = "jellytau"
-version = "0.12.1"
+version = "0.12.2"
 description = "A cross-platform Jellyfin client"
 authors = ["Duncan Tourolle <duncan@tourolle.paris>"]
 license = "MIT"

src-tauri/tauri.conf.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "JellyTau",
-  "version": "0.12.1",
+  "version": "0.12.2",
   "identifier": "com.dtourolle.jellytau",
   "build": {
     "beforeDevCommand": "bun run dev",