Restarting canceled downloads will cancel again

[WebworkrNet]

Once canceled, downloads will cancel again when they are started again.

The only remedy currently is the following workaround:

1. Start the download under a different quality level, if one is offered.
2. Manually cancel this download in alternative quality.
3. Start the download again in the preferred quality.

[WebworkrNet]

Samsung Galaxy XCover 4S Android 10 Zapp 3.6.1

[cemrich]

Thank you very much for your report!

I cannot confirm this bug on Android 11, Poco F1. More research on broader spectrum of devices is needed.

[cemrich]

Funny thing. I don't know what changed, but now I can reproduce it on my device.

Maybe it does not occur for all shows? I used a short ARD show.

Logcat after triggering second download attempt after first failure:

2021-07-08 20:28:35.375 24672-26972/de.christinecoenen.code.zapp D/LibGlobalFetchLib: UpdatedRequest with id: -1922840283 to DownloadInfo(id=-1922840283, namespace='LibGlobalFetchLib', url='https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rH_K1S/_-0S/_Avd5Ard5U1S/3049d3f9-c828-4a19-97f5-73def1c912d6_E.mp4', file='content://media/external_primary/video/media/44155', group=0, priority=NORMAL, headers={}, downloaded=10500438, total=19597094, status=FAILED, error=CONNECTION_TIMED_OUT, networkType=UNMETERED, created=1625768915363, tag=null, enqueueAction=UPDATE_ACCORDINGLY, identifier=81, downloadOnEnqueue=true, extras={}, autoRetryMaxAttempts=0, autoRetryAttempts=0, etaInMilliSeconds=-1, downloadedBytesPerSecond=-1)
2021-07-08 20:28:35.380 24672-24672/de.christinecoenen.code.zapp D/LibGlobalFetchLib: PriorityIterator backoffTime reset to 500 milliseconds
2021-07-08 20:28:35.384 24672-26972/de.christinecoenen.code.zapp D/LibGlobalFetchLib: Queued DownloadInfo(id=-1922840283, namespace='LibGlobalFetchLib', url='https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rH_K1S/_-0S/_Avd5Ard5U1S/3049d3f9-c828-4a19-97f5-73def1c912d6_E.mp4', file='content://media/external_primary/video/media/44155', group=0, priority=NORMAL, headers={}, downloaded=10500438, total=19597094, status=QUEUED, error=NONE, networkType=UNMETERED, created=1625768915363, tag=null, enqueueAction=UPDATE_ACCORDINGLY, identifier=81, downloadOnEnqueue=true, extras={}, autoRetryMaxAttempts=0, autoRetryAttempts=0, etaInMilliSeconds=-1, downloadedBytesPerSecond=-1) for download
2021-07-08 20:28:35.397 24672-24672/de.christinecoenen.code.zapp D/LibGlobalFetchLib: PriorityIterator backoffTime reset to 500 milliseconds
2021-07-08 20:28:35.913 24672-26982/de.christinecoenen.code.zapp D/LibGlobalFetchLib: DownloadManager starting download DownloadInfo(id=-1922840283, namespace='LibGlobalFetchLib', url='https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rH_K1S/_-0S/_Avd5Ard5U1S/3049d3f9-c828-4a19-97f5-73def1c912d6_E.mp4', file='content://media/external_primary/video/media/44155', group=0, priority=NORMAL, headers={}, downloaded=0, total=-1, status=QUEUED, error=NONE, networkType=UNMETERED, created=1625768915363, tag=null, enqueueAction=UPDATE_ACCORDINGLY, identifier=81, downloadOnEnqueue=true, extras={}, autoRetryMaxAttempts=0, autoRetryAttempts=0, etaInMilliSeconds=-1, downloadedBytesPerSecond=-1)
2021-07-08 20:28:36.070 24672-26982/de.christinecoenen.code.zapp D/LibGlobalFetchLib: FileDownloader resuming Download DownloadInfo(id=-1922840283, namespace='LibGlobalFetchLib', url='https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rH_K1S/_-0S/_Avd5Ard5U1S/3049d3f9-c828-4a19-97f5-73def1c912d6_E.mp4', file='content://media/external_primary/video/media/44155', group=0, priority=NORMAL, headers={}, downloaded=0, total=19597094, status=QUEUED, error=NONE, networkType=UNMETERED, created=1625768915363, tag=null, enqueueAction=UPDATE_ACCORDINGLY, identifier=81, downloadOnEnqueue=true, extras={}, autoRetryMaxAttempts=0, autoRetryAttempts=0, etaInMilliSeconds=-1, downloadedBytesPerSecond=-1)
2021-07-08 20:28:36.083 24672-26982/de.christinecoenen.code.zapp E/LibGlobalFetchLib: FileDownloader download:DownloadInfo(id=-1922840283, namespace='LibGlobalFetchLib', url='https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rH_K1S/_-0S/_Avd5Ard5U1S/3049d3f9-c828-4a19-97f5-73def1c912d6_E.mp4', file='content://media/external_primary/video/media/44155', group=0, priority=NORMAL, headers={}, downloaded=0, total=19597094, status=QUEUED, error=NONE, networkType=UNMETERED, created=1625768915363, tag=null, enqueueAction=UPDATE_ACCORDINGLY, identifier=81, downloadOnEnqueue=true, extras={}, autoRetryMaxAttempts=0, autoRetryAttempts=0, etaInMilliSeconds=-1, downloadedBytesPerSecond=-1)
    java.io.FileNotFoundException: java.io.FileNotFoundException: No item at content://media/external_primary/video/media/44155
        at android.database.DatabaseUtils.readExceptionWithFileNotFoundExceptionFromParcel(DatabaseUtils.java:151)
        at android.content.ContentProviderProxy.openAssetFile(ContentProviderNative.java:704)
        at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:1816)
        at android.content.ContentResolver.openFileDescriptor(ContentResolver.java:1631)
        at android.content.ContentResolver.openFileDescriptor(ContentResolver.java:1578)
        at com.tonyodev.fetch2core.StorageResolverHelper.createFileAtPath(StorageResolverHelper.kt:191)
        at com.tonyodev.fetch2core.DefaultStorageResolver.createFile(DefaultStorageResolver.kt:15)
        at com.tonyodev.fetch2.downloader.SequentialFileDownloaderImpl.run(SequentialFileDownloaderImpl.kt:104)
        at com.tonyodev.fetch2.downloader.DownloadManagerImpl$start$$inlined$synchronized$lambda$1.run(DownloadManagerImpl.kt:103)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:923)

[WebworkrNet]

So far I haven't been able to make out any difference in the length of the programs. For me it is a general problem.

[WebworkrNet]

I had emailed several crash reports on this in the past.

[cemrich]

@WebworkrNet I think I fixed the issue in prerelease 4.0.0-beta.1

[WebworkrNet]

Can I install the beta version from GitHub without any problems if I originally obtained the app via F-Droid?

[cemrich]

Can I install the beta version from GitHub without any problems if I originally obtained the app via F-Droid? No, the apps are signed with different keys. But luckily (?) F-Droid choose to ignore the Release-Tag-Passtern and published the beta release as regular app. So you can test the regular way if this issue has been fixed.

[just-Nob]

I updated to latest V.4.0.1 today, but the bug is still present here, i.e. if the download fails , it can only be restarted by the workaround that's described by @WebworkrNet above.

I'm using a Poco X3 running ArrowOS 11.

[cemrich]

@just-Nob Thank you very much for your feedback! It looks like the downloading library Zapp is using is no longer maintained. So I'll have to switch to another implementation anyway.

[just-Nob]

This bug seems to occur especially when downloading videos in highest resolution it seems that this is the situation in which most abortions occur.

Most time it's like described below: Most times when starting to download a high resolution video, the download doesn't complete but aborts after some time, e.g. when about a third is completed. When restarting the download (by using the workaround), then it gets a little further, let's say about ⅜ this time, for example. Next time, it gets a little further again, and so on and so on, until the download is finally finished. It seems to me that everytime the download aborts, the part that's done so far is cached somewhere and by everya new try a little more can be downloaded before it fails again. Maybe the download function is just a little too 'impatient'?

I thought about opening a separate ticket for that, but is it worth it? Maybe I should wait until the new download lib is implemented.

[cemrich]

@just-Nob This might be the same bug as in #224

[just-Nob]

No, it isn't. This happened although Zapp stayed in foreground and I forced the phone to stay awake (screen on).

[cemrich]

@just-Nob Thank you for your feedback. I opened a separate bug. I seems like I have to rewrite the download functionaility from ground up.

[Flo10247]

Found this bug after using the workaround for a long time. I've only a unstable WAN connection via Freifunk, so I have to live with many fails...

I'm actually running LineageOS 18.1 (Android 11) with Zapp 6.0.2.

It's the same bug as on my old Neffos X1 with stock Android 7... Sorry I can't remember the Zapp version.

So I think it's independent from the version, system and filesize. You get the same bug by switching the WiFi off and on again during active download. The download won't resume by touching the button.

I hope this helps a little bit to fix it! ;)

Workaround on top still works!

[cemrich]

I reimplemented the download library with modern Android components which should be much more robust. I'll comment this issue again as soon as the new version is released.