fix(download): remove deleted/cancelled items from the Downloads list in real time (#1227)

[LeC-D]

Fixes #1227.

Problem

When a download is cancelled or deleted, VideoDownloadManager.downloadDeleteEvent fires — but until now only the download button (BaseFetchButton) listened to it. The Downloads page itself never reacted, so a deleted episode/movie card stayed on screen until the user navigated away and back. That stale card is the actual bug reported in #1227 ("UI still showing episodes/movies that were deleted").

Fix

DownloadViewModel — the core #1227 fix. Subscribes to downloadDeleteEvent at the activity-scoped (shared) ViewModel level and removes the deleted id from the header + child lists live, so both DownloadFragment (headers) and DownloadChildFragment (children) refresh with no manual reload. It also clears the id from multi-select state. Uses postValue only, since the event fires on the downloader's background thread. This hooks the event "to update the UI in case of deletion from any source" (result page, queue, notification, …), as the issue asks.

BaseFetchButton — resets the button via resetView() on a matching persistentId; subscription wired in onAttached/DetachedFromWindow, mirroring the existing downloadStatusEvent handling. This keeps an on-screen download button from showing a stale state after a deletion elsewhere.

How to reproduce (the #1227 symptom)

1. Download one or more episodes/movies.
2. Open the Downloads page.
3. Cancel/delete an item from another surface (result page button, download queue, or the download notification).
4. Before: the deleted card stays visible in the Downloads list until you leave and re-enter the page. After: it disappears immediately.

I'm happy to attach a before/after screen recording if useful.

[fire-light42]

Please review our AI Policy https://github.com/recloudstream/cloudstream/blob/master/AI-POLICY.md

[LeC-D]

Hi @fire-light42, thanks for pointing to the AI policy.

To be transparent: this fix was developed with AI assistance (GitHub Copilot / Claude for context exploration). I'm fully responsible for understanding and verifying the code — the approach directly mirrors the existing downloadStatusEvent and downloadProgressEvent patterns already in BaseFetchButton, so the change is straightforward and intentional. I've reviewed and tested the logic manually.

Let me know if you have any concerns about the implementation itself!

[LeC-D]

Updated the PR description to include the AI usage disclosure directly in the body, as required by the AI Policy. Thanks for flagging this, @fire-light42!

[LeC-D]

Rebased on upstream master (2026-04-03) to bring the branch back up to date.

[fire-light42]

Thank you for your contribution!

I will test and review soon. The code looks good, but getting these things right can be tricky.

Do not concern yourself with merge conflicts or keeping the branch up to date, I will resolve any conflicts if necessary 👍

[fire-light43]

I can not replicate the stale download state.
Can you please show a video of it before and after?

[LeC-D]

Quick status update to clear up confusion about what this PR actually does — the original title/description undersold its scope.

The code already covers the full #1227 fix (2 files, the diff hasn't changed):

• DownloadViewModel — the actual Download does not get removed when cancelling from a notification. #1227 fix: subscribes to downloadDeleteEvent at the activity-scoped (shared) ViewModel level and removes the deleted id from the header + child lists live, so both DownloadFragment and DownloadChildFragment refresh with no manual reload. Also clears it from multi-select state. postValue only (the event fires on the downloader's background thread).
• BaseFetchButton — resets the button via resetView() on a matching persistentId; subscription wired in onAttached/DetachedFromWindow, mirroring the existing downloadStatusEvent handling.

Together this hooks downloadDeleteEvent "to update the UI in case of deletion from any source," as the issue asks.

@fire-light43 — I think the earlier difficulty reproducing came from the old description, which pointed at the button rather than the Downloads list. The #1227 symptom is on the list. Repro:

1. Download some episodes/movies.
2. Open the Downloads page.
3. Cancel/delete an item from another surface (result page, queue, or notification).
4. Before: the deleted card stays in the list until you leave and re-enter. After: it disappears immediately.

I've updated the title and description to match. Happy to attach a before/after recording if that helps.