Repository navigation
Publish a new cap-web Docker image with the R2 multipart fixes (#2275) #2384
Description
Hi! Could you publish a new ghcr.io/capsoftware/cap-web image that includes the Cloudflare R2 multipart fixes?
The latest cap-web:latest was built on 2026-09-07 (from c5f22d7), so it doesn't have:
- e65fac6 fix(recorder-core): slice streamed chunks into uniform parts for Cloudflare R2 compatibility (Self-hosted + Cloudflare R2: camera-only Instant recordings fail with "InvalidPart: All non-trailing parts must have the same length" #2275)
- b215b9b fix(recorder): align streamed multipart uploads for R2
- 2237aa8 fix: harden web recording and upload recovery (fix: preserve web recordings through capture and upload failures #2343)
On our self-hosted instance with R2, this hits the web recorder in Chromium browsers too, not only camera-only desktop recordings. The streaming WebM upload flushes parts of about 5.0 to 5.8 MiB, so R2 rejects CompleteMultipartUpload with InvalidPart: All non-trailing parts must have the same length. The client treats the 500 as "uncertain", so the video stays in "uploading" forever and the local spool copy is disposed. 3 of our 16 browser recordings were lost this way.
cap-media-server:latest was already rebuilt on 2026-09-24, so only the web image is behind. Thanks for the fixes!
Activity
linear commentedon Sep 29, 2026
CAP-830
nikhilanu commentedon Oct 21, 2026
Sharing what I have seen on a self-hosted install with Cloudflare R2, in case it's useful:
cap-webfrommain(57369c4). Long recordings from Record in Browser now upload fine for us, and the desktop app (Instant and Studio) works too.InvalidPart: All non-trailing parts must have the same lengthon recordings longer than about a minute. Chrome shows version 1.0.3 after a forced update, and the uploaded parts were uneven (5.26–5.89 MB), so we wondered whether the store version predates the fix.Is a new
cap-webimage and extension release planned?ghcr.io/capsoftware/cap-web:lateststill looks like the 2026-09-07 build.