Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Downloading updates often fail #448
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
acabrol
commented
Sep 23, 2016
|
I have the same issue for the 3 latest updates on my nexus 6p. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment|
See #427. |
thestinger
closed this
Sep 23, 2016
thestinger
added
the
Type: question
label
Sep 23, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 23, 2016
seems to be a different issue I was getting this error from time to time even before Nougat. Anyway I've updated the Updater app but it still fail.
With adb logcat I get:
09-23 17:33:42.557 6972 8555 D DownloadManager: [63] Starting
09-23 17:33:42.681 6972 8296 W DownloadManager: [63] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out
09-23 17:33:42.685 6972 8296 D DownloadManager: [63] Finished with status CANNOT_RESUME
09-23 17:33:44.274 6972 8555 W DownloadManager: [63] Stop requested with status CANNOT_RESUME: Expected partial, but received OK
09-23 17:33:44.274 6972 8555 D DownloadManager: [63] Finished with status CANNOT_RESUME
wcat
commented
Sep 23, 2016
|
seems to be a different issue I was getting this error from time to time even before Nougat. Anyway I've updated the Updater app but it still fail.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 23, 2016
Contributor
That's a genuine issue with your network. The updates are very large since there are no deltas yet (and either way they will only be used if you're on the past version) so it's not surprising that people with flaky connections have issues downloading them.
|
That's a genuine issue with your network. The updates are very large since there are no deltas yet (and either way they will only be used if you're on the past version) so it's not surprising that people with flaky connections have issues downloading them. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 23, 2016
Contributor
Download it on a more reliable connection, or download it on another machine and sideload it.
|
Download it on a more reliable connection, or download it on another machine and sideload it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 23, 2016
In the case it is still a bug of the updater since the connection is stable. I can download them with no issues with web browsers/wget/...
I also get those messages before the others:
09-23 17:23:40.618 7937 8292 D DownloadService: Looking for incremental ota for source=2016.09.14.05.23.28, target=2016.09.21.10.30.07
09-23 17:23:40.678 7937 7959 D NetworkSecurityConfig: No Network Security Config specified, using platform default
09-23 17:23:42.041 7937 7937 V DownloadService: Downloading full zip
09-23 17:23:42.117 6972 8296 D DownloadManager: [63] Starting
09-23 17:23:42.155 6972 8296 W System : ClassLoader referenced unknown path:
09-23 17:23:42.155 6972 8296 W System : ClassLoader referenced unknown path: /data/app/com.cyanogenmod.updater-1/lib/arm64
09-23 17:33:42.495 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. c9d92a0 #u0a8/63 DownloadManager:com.android.providers.downloads
I will try by sideloading it.
wcat
commented
Sep 23, 2016
|
In the case it is still a bug of the updater since the connection is stable. I can download them with no issues with web browsers/wget/... I also get those messages before the others:
I will try by sideloading it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 23, 2016
Contributor
In the case it is still a bug of the updater since the connection is stable.
It's not an updater bug. It's not even the updater downloading it, it's Android's standard DownloadManager service as you can see from the log. It's identical to stock Android.
It's not an updater bug. It's not even the updater downloading it, it's Android's standard DownloadManager service as you can see from the log. It's identical to stock Android. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 23, 2016
still weird that with the same device/network:
- if I download it "trough" the updater it will always fail
- if download trough web browsers/wget it will always succeed
wcat
commented
Sep 23, 2016
|
still weird that with the same device/network:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 23, 2016
Contributor
It doesn't mean it's a bug. It looks like it's timing out, which could be because the speed dropped below a minimum threshold for too long. I'm not going to believe it's a bug without evidence. It works fine for all but a rare few people and it's the standard Android DownloadManager without modifications.
|
It doesn't mean it's a bug. It looks like it's timing out, which could be because the speed dropped below a minimum threshold for too long. I'm not going to believe it's a bug without evidence. It works fine for all but a rare few people and it's the standard Android DownloadManager without modifications. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 24, 2016
ok I've done some further testing: the issue seems to be in fact related to DownloadManager since even if I use Chromium the connection is still dropped but not if I use Fennec or wget.
However it's almost surely not a network issue since the connection is dropped exactly 10 minutes after it starts (I've tested this multiple times). You can see it from the previous logs:
09-23 17:23:42.117 6972 8296 D DownloadManager: [63] Starting
09-23 17:33:42.495 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. c9d92a0 #u0a8/63 DownloadManager:com.android.providers.downloads
another example:
09-24 09:29:29.133 6972 20556 D DownloadManager: [69] Starting
09-24 09:39:29.129 4546 4546 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 91e3188 #u0a8/69 DownloadManager:com.android.providers.downloads
wcat
commented
Sep 24, 2016
|
ok I've done some further testing: the issue seems to be in fact related to DownloadManager since even if I use Chromium the connection is still dropped but not if I use Fennec or wget.
another example:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 24, 2016
to make things even more weirder downloading other files with DownloadManager like copperhead factory images doesn't cause the issue. So far it seems that the timeout occurs only with copperhead updates, regardless if the download is started from chromium or from the updates list.
I managed to download the update in less than 10 minutes by using the mobile connection (which is a lot faster) and also with the newest update this issue is still present.
wcat
commented
Sep 24, 2016
•
edited
Edited 1 time
-
wcat
edited Sep 26, 2016
edited
-
Sep 26, 2016
|
I managed to download the update in less than 10 minutes by using the mobile connection (which is a lot faster) and also with the newest update this issue is still present. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 26, 2016
Ok forget the previous post I've probably downloaded the factory image using the mobile connection the issue is always reproducible.
To reproduce it just open logcat:
adb logcat | grep DownloadManager
and download a file (with DownloadManager, for example by using Chromium) big enough to let the download last more than 10 minutes (or limit the bandwith accordingly) for example this file https://dumps.wikimedia.org/other/pagecounts-ez/wikistats/csv_wp_edits.zip is 8.7GB it should be big enough. Otherwise here there are files of various sizes https://dumps.wikimedia.org/other/pagecounts-ez/wikistats/.
Exactly every 10 minutes the download will get interrupted, and there are two cases:
- the web server support resuming: then the download will restart and it will be interrupted again after 10 minutes;
- the web server doesn't support resuming: then the download will fail
If you try with the previous link you will experience the first behaviour, this is an example of the output:
09-26 15:59:09.536 21252 23846 W DownloadManager: Path appears to be invalid: /storage/emulated/0/Download/csv_wp_reverts.zip
09-26 15:59:09.653 21252 28847 D DownloadManager: [93] Starting
09-26 15:59:11.418 21252 28847 W DownloadManager: fallocate() not supported; falling back to ftruncate()
09-26 16:09:09.649 4669 4669 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 1dd9c05 #u0a8/93 DownloadManager:com.android.providers.downloads
09-26 16:09:09.732 21252 29405 D DownloadManager: [93] Starting
09-26 16:09:09.828 21252 28847 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out
09-26 16:09:09.829 21252 28847 D DownloadManager: [93] Finished with status WAITING_TO_RETRY
09-26 16:09:12.399 21252 29405 W DownloadManager: fallocate() not supported; falling back to ftruncate()
09-26 16:09:12.556 21252 29405 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out
09-26 16:09:12.559 21252 29405 D DownloadManager: [93] Finished with status WAITING_TO_RETRY
09-26 16:09:45.993 21252 29433 D DownloadManager: [93] Starting
09-26 16:09:47.458 21252 29433 W DownloadManager: fallocate() not supported; falling back to ftruncate()
09-26 16:19:45.993 4669 4669 I JobServiceContext: Client timed out while executing (no jobFinished received). sending onStop. 534ce7a #u0a8/93 DownloadManager:com.android.providers.downloads
09-26 16:19:46.072 21252 29816 D DownloadManager: [93] Starting
09-26 16:19:46.157 21252 29433 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out
09-26 16:19:46.160 21252 29433 D DownloadManager: [93] Finished with status WAITING_TO_RETRY
09-26 16:19:47.822 21252 29816 W DownloadManager: fallocate() not supported; falling back to ftruncate()
09-26 16:19:47.975 21252 29816 W DownloadManager: [93] Stop requested with status HTTP_DATA_ERROR: Local halt requested; job probably timed out
09-26 16:19:47.978 21252 29816 D DownloadManager: [93] Finished with status WAITING_TO_RETRY
The issue at hand with the updater is that the resume is not supported on the web server which hosts the copperhead updates, so unless you have a connection faster enough to download it in less than 10 minutes the download is going to fail.
wcat
commented
Sep 26, 2016
•
edited
Edited 1 time
-
wcat
edited
Sep 26, 2016
edited
-
Sep 26, 2016
|
Ok forget the previous post I've probably downloaded the factory image using the mobile connection the issue is always reproducible. To reproduce it just open logcat: Exactly every 10 minutes the download will get interrupted, and there are two cases:
If you try with the previous link you will experience the first behaviour, this is an example of the output:
The issue at hand with the updater is that the resume is not supported on the web server which hosts the copperhead updates, so unless you have a connection faster enough to download it in less than 10 minutes the download is going to fail. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 26, 2016
the bug should probably reopened, since the logs prove that almost surely that this is not caused by a network error.
wcat
commented
Sep 26, 2016
|
the bug should probably reopened, since the logs prove that almost surely that this is not caused by a network error. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 26, 2016
Contributor
It's not a bug. We aren't going to be moving away from OpenShift and it prevents having a proper Content-Length for these files which would alleviate most annoyances like this.
|
It's not a bug. We aren't going to be moving away from OpenShift and it prevents having a proper Content-Length for these files which would alleviate most annoyances like this. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 26, 2016
Contributor
i.e. take it up with OpenShift (the fact that they force gzip compression for all files, don't respect no-transform, and they do it in a non-standards-compliant way that breaks the headers)
|
i.e. take it up with OpenShift (the fact that they force gzip compression for all files, don't respect no-transform, and they do it in a non-standards-compliant way that breaks the headers) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
wcat
Sep 26, 2016
well dropping the connection every 10 minutes for "no" reasons is (imho) kind of a bug.
Since sideloading require unlocking the device (and thus wiping the data), as a workaround is there a way to "trick" the updater to use an already downloaded file?
wcat
commented
Sep 26, 2016
|
well dropping the connection every 10 minutes for "no" reasons is (imho) kind of a bug. Since sideloading require unlocking the device (and thus wiping the data), as a workaround is there a way to "trick" the updater to use an already downloaded file? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 26, 2016
Contributor
well dropping the connection every 10 minutes for "no" reasons is (imho) kind of a bug.
It's not for no reason, and it's not a bug.
Since sideloading require unlocking the device (and thus wiping the data)
Sideloading doesn't require unlocking the device.
as a workaround is there a way to "trick" the updater to use an already downloaded file?
No.
It's not for no reason, and it's not a bug.
Sideloading doesn't require unlocking the device.
No. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Sep 26, 2016
Contributor
I'm not interested in arguing about this. If someone wants to finally get the Content-Length issue solved, take it up with OpenShift. It's not our fault that it can't track progress.
|
I'm not interested in arguing about this. If someone wants to finally get the Content-Length issue solved, take it up with OpenShift. It's not our fault that it can't track progress. |
wcat commentedSep 23, 2016
it happens quite often that some updates are simply impossible to download on my nexus 5x. The procedure, after a while, fails by telling me that the update download was unsuccessful. It is possible (but I don't know how to check if it is so) that it fails immediately after it has fully downloaded the update (some failure in checking signatures/hashes?).
It is happening now with 2016.09.21.10.30.07 and with 2016.09.17.19.33.24.
Rebooting the phone or trying many times the download doesn't help. I simply have to wait for other updates.