From 08008ca6f958fe9f2768447047b3225292f10ca7 Mon Sep 17 00:00:00 2001 From: Justin L Date: Tue, 6 Jan 2026 09:03:44 -0500 Subject: [PATCH] Fix download resume corruption when server returns HTTP 200 When resuming a download after interruption, if the server returns HTTP 200 (full resource) instead of HTTP 206 (partial content), the code correctly resets mMission.done but fails to reset the 'start' variable. This causes the subsequent file seek to use a stale offset, writing new data at incorrect positions. This bug causes file corruption for large downloads (>5GB) that are interrupted and resumed, particularly when: - Switching between WiFi networks - Server CDN returning different responses - Connection drops during long downloads The corruption manifests as duplicate data regions in the file, which for MP4 downloads results in multiple MOOV atoms and broken seek functionality. Fix: Reset start=0 when HTTP 200 is received, ensuring the file write position correctly restarts from the beginning of the current resource. --- .../main/java/us/shandian/giga/get/DownloadRunnableFallback.java | 1 + 1 file changed, 1 insertion(+) diff --git a/app/src/main/java/us/shandian/giga/get/DownloadRunnableFallback.java b/app/src/main/java/us/shandian/giga/get/DownloadRunnableFallback.java index eed5db463..1d2483e79 100644 --- a/app/src/main/java/us/shandian/giga/get/DownloadRunnableFallback.java +++ b/app/src/main/java/us/shandian/giga/get/DownloadRunnableFallback.java @@ -85,6 +85,7 @@ public class DownloadRunnableFallback extends Thread { if (mMission.unknownLength || mConn.getResponseCode() == 200) { // restart amount of bytes downloaded mMission.done = mMission.offsets[mMission.current] - mMission.offsets[0]; + start = 0; // reset position to avoid writing at wrong offset } mF = mMission.storage.getStream();