|
|
Rank: Newbie
Groups: Member
Joined: 1/7/2020
Posts: 7
|
I've evaluating using EO to replace the WebBrowser control because of HTML5. One of the functions the browser is used for is to download files in the 4-6GB range. With the EO browser the download stops after anywhere between 50MB and 500GB. I've tried it with coding for; LoadURL
,Download and DownloadwithResult. No error messages are produced with any of the methods, it just quits the download.
I've been doing most of my testing in Visual Studio, but got the same results running the executable outside of Visual Studio.
The same link consistently downloads in full with the legacy web browser control. I've done the same download in the web browser control before after and during testing of the EO Browser with no issues so the issues does not appear to be connection or hardware related.
I have not had any issues in the EO browser with sequentially downloading a couple of hundred 2-5 MB files, just large ones which leads me to believe there is some configuration or setting to handle large files that I am missing.
I really like the EO browser so I'm hoping there is a setting or something that I missed configuring.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
The download is handled by the Chromium browser engine and we do not do anything particular with it beside monitoring the notifications in order to raises corresponding events. Please try the following:
1. Try to download the same file with Google Chrome browser and see if it works correctly.
2. If that works fine, please try to download the link through our TabbedBrowser sample application;
If it works in Google Chrome browser but does not work in TabbedBrowser, please PM us with the link and we will try to debug into the code here to see what we can find.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 1/7/2020
Posts: 7
|
Chromium threw a network error and marked the download as failed. I had to hit resume multiple times to get it to fully download the file.
The tabbed browser sample successfully downloaded the file multiple times with a couple of notable progress pauses even when the Chromium browser continued to throw errors network failure errors during concurrent testing.
I'm going to have to chase down why Chromium appears to be more sensitive to network issues than Firefox, Opera, Edge and my custom application with IE 11 as I was able to download the same file multiple times in those browsers without issue.
I'm going to have to assume there is some coding in the tabbed browser sample that is handling the network error thrown by Chromium and automatically resuming the download and is not being addressed in my code. If you can point me to where I should be looking in the sample code that would be helpful.
Unfortunately, I can't provide a sample link because the content is for internal company use only.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
If the root problem is network, then there probably isn't much you or us can do. TabbedBrowser in fact does not do additional error handling for downloading, but since the status change/notifications are rerouted from the native browser engine through the .NET host application (and then through the UI to show download progress in the case for TabbedBrowser), it might have some impact on event timing, which could be what actually made it less sensitive to the underlying network problems. So unfortunately there isn't anything we can point you to in the sample code. :(
|
|
Rank: Newbie
Groups: Member
Joined: 1/7/2020
Posts: 7
|
I can't see how it is an actual network issue given that all of the other browsers download the same file with no issues much quicker. In researching it, this does appear to be a Chrome issue as there are several blogs and YouTube videos out there complaining about Chrome and large files. Someone even wrote an auto resume extension for it which I have installed in Chrome and been have been able to download the file multiple times with no issues until I disabled the extension.
My solution appears to be to code a timer to check on any downloads in the queue to see if they have timed out and if so automatically fire the resume depending on the status message.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Yes. That could work. It can still be a network issue and it's just other browsers are more tolerant to it but Chromium is more sensitive to it, even though I do not know why Chromium would not implement a simple retry logic as you mentioned. You can try to implement the timer logic and let us know if you run into any problems.
|
|
Rank: Newbie
Groups: Member
Joined: 1/7/2020
Posts: 7
|
The timer did not work. The download status shows "in progress", error code "OK" and current speed "0". The EO browser never gets the error state Chrome throws when downloading the same file. I modified it so that under those condition it would pause and resume, but that did nothing.
In further testing the sample browser failed also, exact same behavior where is would just show "in progress". I would think that at some point of continuous 0 speeds the wrapper would throw an error, but I let go for 10 minutes with no change. There seems to be a definite gap there in how the wrapper communicates with Chrome.
I did try a couple of public download servers and was able to download a couple of 10 GB test files with no issues so there may be something out our cloud server the Chromium doesn't like so I have opened an internal ticket but it is doubtful I'll see much movement on that front given the user base is not impacted.
I know this is hard to replicate, but it seems worth noting there are definitely conditions under which Chrome registers a network failure and the EO browser just continues waiting even though the current speed is continuously 0 because Chrome has stopped attempting the download.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
I agree with you that it's unlikely that you will see movements on this on the Chromium front given their user base size. We will be more than happy to dig into the browser engine code to see what we can find if somehow you can provide a test server/link for us to duplicate the problem. For this kind of issue, there is no chance to get anywhere just by speculating. The only way to get to the bottom is to duplicate the issue and debug into the source code in a test environment.
|
|
Rank: Newbie
Groups: Member
Joined: 1/7/2020
Posts: 7
|
The issue was being caused by Kapersky Total Security with the encrypted scanning option turned on. It was apparently creating a delay Chrome is extremely sensitive to.
That said there is still a messaging gap between the EO Browser and functionality in Chrome where it is able to resume a download that throws the Network Failed error. The gaps are:
1. The webview never enters an error state for the download when CurrentSpeed is a constant 0 for an extended period of time. It would be helpful if there were a download timeout setting that could be configured that would put the download in an error state if it goes X seconds at a continuous CurrentSpeed of 0
2. Pausing and resuming when in this state appears to have no affect on getting the download out of that state. My guess is that the proper messaging is not getting sent to Chrome to get it to resume a download it stopped due to the network failed message
3. In Chrome I am able to resume downloads that throw that error, but I was unable to figure out any coding solution with the webview to replicate resuming a download that had stopped due to an error. I'm not sure how Chrome handles the retry, but if it is exposed it is probably different messaging than the resume from a pause
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
Glad to hear that at least you found out what's causing it. My guess is that Google Chrome has a timeout mechanism that automatically closes the download connection which causes it to fail. This would then give the user option to restart the download through a new connection, but using HTTP range request which would allow the download to resume from where it is left off. This can either be implemented inside or outside of the core browser engine. Most likely this is implemented outside of the core browser engine (you can think it as the "Chrome" part, not the "Chromium" part) since otherwise EO.WebBrowser would automatically inherit this ability.
We can look into Chrome's source code to see how this is implemented and see if it is possible to port this part over. Usually if it is not too much code changes we can port it over but if the changes are extensive, then we will not be able to add it because the more extensive the change is, the higher the risk that we would break something else. Since we can not sacrifice the stability of the product, usually we would decide against the change in such case.
We will reply again when we have more information.
Thanks!
|
|