Add configurable download size limit and chunk size for large file downloads

[Enqvy]

Problem

• Currently, when attempting to download files above a size threshold, the operation fails with a generic log message: "WARN range-parallel: Content-Range total x > 50,000,000 for https://example.com/smth.zip is too large; falling back to single GET" The app attempts to fetch the entire file in a single GET request, but each request is apparently capped at 50MB and times out before completion. This makes downloading large files impossible.

Proposed Solution

• Add power-user controls to make large file downloads configurable and reliable:

• Toggle switch – Enable/disable download size limit enforcement

• Slider control – Set download fragment/chunk size (range: 256KB up to the maximum limit) Note: Im adding this because going higher than 256kb, will be a bit slower but use less request quota

This would allow users to:

• Bypass arbitrary size restrictions when needed
• Fine-tune chunk sizes to optimize for their conditions

[therealaleph]

Hey @Enqvy — thanks, this is a well-framed report. Let me explain what's actually going on so we can see which knobs would help and which can't.

There are two thresholds in play, and they're both real but only one is ours:

1. Range-parallel stitching cap (ours): MAX_STITCHED_RANGE_BYTES = 64 MiB in src/domain_fronter.rs:66. We split files into 256 KiB chunks, fetch them in parallel through Apps Script, and stitch them back. We cap stitching at 64 MiB so a hostile origin can't claim a 100 GB Content-Range and get us to allocate ridiculous memory.
2. Apps Script per-fetch cap (Google's): 50 MiB on a single UrlFetchApp.fetch() call. This is hard-coded at Google's end — we can't raise it. When range-parallel fails any chunk validation (origin returns 200 instead of 206, Content-Range header stripped, etc.) we fall back to a single GET without Range, and that's the path that runs into the 50 MiB Apps Script ceiling.

So the failure shape for a >50 MiB file is:

• Range-parallel works fine if origin cooperates → stitches up to 64 MiB → success
• Range-parallel fails any chunk → fallback single-GET → Apps Script truncates at 50 MiB → file looks complete but is corrupt at byte 50,000,000

Which of your asks helps:

• ✅ Configurable chunk size slider (256 KiB → 1 MiB or 2 MiB): actually useful. Bigger chunks reduce request count, which matters for the 20k/day Apps Script quota. Tradeoff is per-request size — go too big and a chunk request hits the 50 MiB cap on its own. Reasonable cap on the slider would be ~10 MiB (gives you 5x fewer requests for a 50 MiB file vs. the current 256 KiB without risking the per-fetch limit). I'd accept this as a config option.

• ✅ Raise MAX_STITCHED_RANGE_BYTES: 64 MiB → 256 MiB would be safe. Each chunk is content-validated before stitching, so the only risk was unbounded allocation, and 256 MiB is fine. This would let range-parallel handle larger files when the origin cooperates.

• ❌ Toggle to disable the size cap entirely: this one I can't do, regardless of UI. The 50 MiB Apps Script per-fetch limit is enforced server-side at Google. No client-side toggle changes that. The cap on our side is preventing memory blowup on a hostile response, not arbitrary.

What actually solves >50 MiB downloads end-to-end:

Full mode (tunnel-node on a VPS) bypasses Apps Script entirely for the data path. Apps Script is just the rendezvous; the actual bytes flow through the VPS, which has no per-request cap. A 5 GB ISO download works the same as a 50 KB image. If you regularly need files >50 MiB, that's the right setup; ~$5/month for a basic VPS.

Concrete proposal for the apps_script-mode case:

I'd take a PR (or implement myself in a v1.7.x release) that:

1. Adds relay_chunk_size_bytes to config.json (default 256 KiB, valid range 64 KiB → 4 MiB)
2. Adds relay_max_stitch_bytes to config.json (default 64 MiB, valid range up to 256 MiB)
3. Surfaces both in the desktop UI under an "Advanced" section
4. Documents the 50 MiB single-GET fallback ceiling as a known Apps Script limit, not a setting

For the chunk-size slider in the Android UI specifically: doable but lower priority since most >50 MiB downloads on Android are app installs / video streaming, both of which are way better served by Full mode anyway.

Does that match what you were after? If you want to take a stab at a PR for (1) + (2) + the desktop UI piece, happy to review.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}