Downloader breaks on network interruption — no retry, broken resume, lost metadata, ghost buttons

[anees-dahot]

Steps to reproduce

1. Start downloading any episode, movie
2. Turn off WiFi mid-download
3. Turn WiFi back on
4. Download fails and download button is unresponsive
5. Force stop app, reopen, tap Resume — nothing happens
6. Switch to another app and back, tap Resume — still nothing
7. Progress shows X MB / 0 KB

Expected behavior

Download should automatically retry or resume when network is restored.
Progress metadata (total file size) should be preserved on interruption.
Resume button should either work or show a clear error message.

Actual behavior

Bug 1: Download dies permanently on WiFi drop, no retry attempted, button becomes unresponsive.

Bug 2: After force stop + reopen, Resume button shows but tapping does nothing.
Zero network activity in logcat — stored URL has likely expired (Cloudflare Workers
temporary signed URL) and app silently fails with no user feedback.

Bug 3: Progress shows "10 MB / 0 KB" — totalBytes metadata is lost on interruption,
making resume calculation impossible.

Bug 4: After backgrounding and returning to app, Resume button appears active but
does nothing — DownloadQueueService was killed by Android but UI was never updated.

Cloudstream version and commit hash

4.6.2-PRE - 1fb6ce3

Android version

15

Logcat

Some important logs

java.net.SocketException: Software caused connection abort
java.net.UnknownHostException: Unable to resolve host "worker-shiny-sun-14b1.xesitif709.workers.dev"
java.net.ConnectException: failed to connect to /188.114.97.7 (port 443): ENETUNREACH (Network is unreachable)

Other details

Root cause analysis:

• No SocketException/ConnectException catch with retry logic in the download loop
• Expired URLs are not re-extracted on resume — stored URL used blindly
• totalBytes not written to disk atomically with chunk data
• DownloadQueueService lifecycle not synced back to UI on app resume

Suggested fix: Add external downloader support (1DM, ADM) via Android Intent
as a setting. These apps handle retry, resume, metadata and background correctly.
Would be a useful workaround while the internal downloader is improved.

Device: Mali GPU.

Acknowledgements

• I am sure my issue is related to the app and NOT some extension.
• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• I have written a short but informative title.
• I have updated the app to pre-release version Latest.
• I will fill out all of the requested information in this form.

[recloudstream]

Hello anees-dahot.
Please do not report any provider bugs here. This repository does not contain any providers. Please find the appropriate repository and report your issue there or join the discord.

Found provider name: Sync

[fire-light42]

I am unable to replicate the issue.
Please attach a video demonstrating the issue.

[anees-dahot]

https://streamable.com/831qux

Here's video, you can see the issue here.

[fire-light42]

Thank you for the video

I think the source you are trying to download from cannot be resumed (the server forbids it). The downloader should of course show this more clearly, but the core issue of resumption is not possible to resolve if this is the case.

Does the issue persist when downloading videos from DailyMotion in official extension repository?: https://raw.githubusercontent.com/recloudstream/extensions/refs/heads/master/repo.json

That would help determine if it is a source or app issue.

[anees-dahot]

Dailymotion has same issue.

i have checked many providers almost every has this same issue. So i dont think it can be a provider issue.

Also the provider i am downloading from, that site has 24 hours expiry time for its download links, and this issue comes even just after 5 mints of downloading.

[anees-dahot]

I also am App Developer but not from Kotlin side. I gave this whole codebase to claude and ran it, and thats what it found

After deeper investigation with static analysis, I found this is not an
extension issue — there are 7 interconnected bugs in the core downloader
across 4 files. Here's the full breakdown:

---

Bug 1 — Resume state wiped on any failure

cleanup() always emits DownloadActionType.Stop even for IsFailed.
DownloadQueueService deletes both KEY_RESUME_PACKAGES and
KEY_RESUME_IN_QUEUE on any Stop event — including transient network
failures. This wipes the exact data needed to resume.

• DownloadManager.kt:1650, 1664
• DownloadQueueService.kt:125

---

Bug 2 — Single immediate retry before network recovers

downloadFromResume() retries the same link exactly once with zero delay.
Since WiFi is still down at that moment, the retry fails immediately and
triggers the Stop cleanup from Bug 1.

• DownloadManager.kt:1742

---

Bug 3 — finally block forces every non-success into failure

finally { isFailed = !isCompleted } converts every non-success path
(including transient interruptions) into a permanent failure, which
triggers the Stop cleanup and wipes resume state.

• DownloadManager.kt:1766

---

Bug 4 — Resume button shows but silently does nothing

In DownloadButtonSetup, if getDownloadResumePackage returns null
(because Bug 1 deleted it), it just emits a Resume event with no active
instance to handle it. The button appears active but nothing happens.

• DownloadButtonSetup.kt:77

---

Bug 5 — totalBytes = 0 hides resume option entirely

When DownloadedFileInfo.totalBytes was never persisted (or lost), the UI
uses totalLength + 1 in the denominator and treats any non-zero partial
file as 100% complete — hiding the resume option completely.

• BaseFetchButton.kt:24
• PieFetchButton.kt:203

---

Bug 6 — Network errors in resolveSafe() silently swallowed

Network errors inside LazyStreamDownloadData.resolve() are swallowed and
unknown-end chunks are treated as success. An interrupted download can be
marked complete even if the file is truncated, so resume is never offered.

• DownloadManager.kt:770, 818

---

Bug 7 — Completion only checks minimumSize, not actual total

downloadThing() only checks that downloaded bytes exceed minimumSize
to mark success. If total size is unknown or errors occur late, a partial
file larger than minimumSize gets marked as complete, preventing resume.

• DownloadManager.kt:1185

---

How these bugs chain together

Network drops
  → retry fails immediately with no delay        (Bug 2)
  → finally block forces permanent failure        (Bug 3)
  → cleanup() wipes resume package               (Bug 1)
  → Resume button silently does nothing          (Bug 4)
  → UI hides resume option anyway                (Bug 5)
  → Even if resumed, truncated file = success    (Bug 6, 7)

Every layer has a bug that makes the others worse. This is why the issue
feels impossible to recover from once a network drop happens.

[fire-light42]

I tested on an emulator and the instant retry on network is indeed the core issue. My device simply times out very slowly instead of erroring instantly.

The other "bugs" I am less sure about.

[anees-dahot]

I am fixing these issues on my own, and i have made quite progress. If all goes well then i will make a PR also to contribute.

[xx-ZORO-xx]

I tested on an emulator and the instant retry on network is indeed the core issue. My device simply times out very slowly instead of erroring instantly.

The other "bugs" I am less sure about.

@fire-light42. Bro can you please fix this. Plzzz #2548

[anees-dahot]

I tested on an emulator and the instant retry on network is indeed the core issue. My device simply times out very slowly instead of erroring instantly.
The other "bugs" I am less sure about.

@fire-light42. Bro can you please fix this. Plzzz #2548

@xx-ZORO-xx I think this can be implemented, BUT devs have made that search icon on show for a reason.

The search icon on each show work as it searches that show from all extensions you have installed, thats the default behavior of that search.

Though we can add a toggle in settings like search icon on shows page should search across all installed extensions or just from pinned ones.

[xx-ZORO-xx]

It's not just the shows. Movies are also having the same problem

[xx-ZORO-xx]

I tested on an emulator and the instant retry on network is indeed the core issue. My device simply times out very slowly instead of erroring instantly.
The other "bugs" I am less sure about.

@fire-light42. Bro can you please fix this. Plzzz #2548

@xx-ZORO-xx I think this can be implemented, BUT devs have made that search icon on show for a reason.

The search icon on each show work as it searches that show from all extensions you have installed, thats the default behavior of that search.

Though we can add a toggle in settings like search icon on shows page should search across all installed extensions or just from pinned ones.

That sounds like a great solution. Adding a toggle in the settings should work well.
Thank you!