Pausing download/ejecting app while in progress makes download unrecoverable

[ballo]

Checklist

• I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected version

27

Steps to reproduce the bug

1. Initiate download
2. Pause download/let it continue.
3. Use heavy apps to eject Newpipe from RAM/close Newpipe in any other way.
4. Open Downloads.

Expected behavior

NewPipe will delete the paused download if it gets swapped out of ram. The file remains, but NewPipe can only overwite it rather than resume. This doesn't appear to be a problem if the download is interrupted. In this case. It will change the status of the download in the notifications and will always allow the download to be resumed. The issue is if you pause the download.

Current work-arounds:

1. Disconnect data to cause the download interrupted error which works unlike pausing the download
2. Use something else like yt-dlp (my current solution)

Actual behavior

No response

Screenshots/Screen recordings

No response

Logs

No response

Affected Android/Custom ROM version

No response

Affected device model

No response

Additional information

Mod Edit: Please also check #9557 #10527 while solving this bug, look related.

[opusforlife2]

To be clear, the app handles ejection from RAM properly for an interrupted download, but not a paused one?

[ballo]

To be clear, the app handles ejection from RAM properly for an interrupted download, but not a paused one?

That's the behavior I witnessed, yes

[NewNewPipe]

Nihil novi...
Old problem
#7059

[liloman]

I found the bug on DownloadManager.loadPendingMissions:

if (mis == null || mis.isFinished() || mis.hasInvalidStorage()) {
                //noinspection ResultOfMethodCallIgnored
                sub.delete();
                continue;
            }
   mis.threads = new Thread[0];

  boolean exists;
            try {
                mis.storage = StoredFileHelper.deserialize(mis.storage, ctx);
                exists = !mis.storage.isInvalid() && mis.storage.existsAsFile();
            } catch (Exception ex) {
                Log.e(TAG, "Failed to load the file source of " + mis.storage.toString(), ex);
                mis.storage.invalidate();
                exists = false;
            }

In this commit mis.hasInvalidStorage() is called before mis.storage being deserialized (resulting in always failing in checking if "mis.storage.existsAsFile" ) and hence executing sub.delete(); (deleting the pending downloads)

1822d21

The solution is just remove that redundant check that was done after anyway:

if (mis == null || mis.isFinished() ) {
                //noinspection ResultOfMethodCallIgnored
                sub.delete();
                continue;
            }
...

It's quite a nasty bug because many people use mainly the download function and till version 0.21.8 was working properly (2021).

[Stypox]

@liloman sorry for the late response, and thank you for investigating! Could you open a pull request? Otherwise let me know, I can open one myself. :-)

By the way, we are receiving many reports of this bug in the email, too.