From e80c60c9f110cdf04080c176716bb0e0a95e8e04 Mon Sep 17 00:00:00 2001 From: Mathieu Moran Date: Sun, 9 Aug 2026 01:13:09 -0400 Subject: [PATCH] Document real-hardware phone-relay test results in PLAN.md Deployed and tested the phone-relay feature end-to-end for real: found and fixed a deploy gap (CORS fix wasn't rebuilt into the actual remote server's Docker image, only pulled on the Pi - surfaced as a generic "TypeError: Failed to fetch" in the browser). After fixing, measured real throughput from server-side chunk timestamps: ~1.11MB/s via phone relay (home WiFi) vs ~9-10Mbit/s for the Pi's own direct upload - statistically the same. Confirms the relay provides no speed benefit when the phone is on the same home WiFi as the Pi, since the download-to-phone leg pays the same congested-radio cost either way. Documented this finding plus a follow-up idea (per-clip browse/select upload from the phone, not yet designed). --- PLAN.md | 37 +++++++++++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 4 deletions(-) diff --git a/PLAN.md b/PLAN.md index 943d024..bec649f 100644 --- a/PLAN.md +++ b/PLAN.md @@ -525,10 +525,39 @@ each chunk to the mock-backed server -> verify the reassembled file matches the byte-for-byte via SHA256 -> mark uploaded on the Pi -> confirm it drops out of the pending list. Also verified: path-traversal attempts on `/api/dash/file/` correctly 404, the relay heartbeat/stop lease correctly pauses/resumes `_upload_dashcam_files()`, and the sha256 cache -table is populated and reused across repeated `/api/dash/pending` calls. **Not yet tested on a -real phone against the real deployed server** — the wire protocol and every server-visible -behavior is verified, but real mobile-browser quirks (background-tab throttling, flaky cellular -mid-transfer) haven't been exercised against live hardware yet. +table is populated and reused across repeated `/api/dash/pending` calls. + +**Deploy gotcha found**: the CORS fix in `server/app.py` was initially deployed to the Pi but not +rebuilt on the actual remote server (the server's Docker image bakes `app.py`/`modules/` in at +build time via `COPY`, so a plain `git pull` + container restart isn't enough — needs +`docker compose build api && docker compose up -d api`). Without it, the phone's cross-origin +`fetch()` calls to `yaris.ceaf.dev` were silently blocked by the browser's CORS policy, which +surfaces in JS as a generic, unhelpful `TypeError: Failed to fetch` — worth remembering as the +first thing to check if this error reappears after a future server-side change. + +**Tested for real against a real phone and the real deployed server** (first end-to-end proof +beyond the local simulation above): the initial `/api/dash/pending` call took ~25 minutes for a +one-time full-backlog SHA256 hash of all 87 files (~28GB, no cache existed yet) — after that, +repeat calls returned in ~0.13s. The user then successfully relayed a real file from their phone +(home WiFi) partway through (10/~12 chunks) before stopping to check something important: **is +the relay actually faster, given the phone downloads from the Pi over the same congested radio +diagnosed as the bottleneck?** Measured directly from chunk-arrival timestamps on the server: +**~1.11MB/s (~8.9Mbit/s) for the phone-relay path — statistically the same as the ~9-10Mbit/s +measured for the Pi's own direct Cloudflare upload** earlier this session. **Conclusion: when the +phone is on the same home WiFi as the Pi, the relay provides no speed benefit** — the +download-to-phone leg pays the exact same slow-radio cost as a direct Pi upload would, and the +phone's reupload leg then goes out through the same home internet connection anyway, adding an +extra hop for no gain. The relay only has genuine value when the phone's *second* leg differs +meaningfully from the Pi's own path — e.g. cellular data with better upload than the home ISP, or +uploading after physically leaving home with files already grabbed locally. Stopped the test relay +(`POST /api/dash/relay/stop`) and confirmed the Pi's own background uploader resumed the same +file's chunked upload exactly where the phone left off (shared `/status`/`.upload_tmp` state on +the server made this seamless, no wasted re-transfer). + +**Next idea (not yet built)**: the user wants a way to browse/preview individual dashcam clips on +the phone and select specific ones to view or upload (as opposed to bulk-relaying the entire +backlog) — useful for "just grab this one important clip" rather than a wholesale speed +optimization. Not scoped/designed yet. ## Working Notes / Environment Gotchas