[jsword-devel] [JIRA] Commented: (JS-133) Percentage complete during a download should reflect file size

[Martin Denham (JIRA)]

    [ http://www.crosswire.org/bugs/browse/JS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631#action_13631 ] 

Martin Denham commented on JS-133:
----------------------------------

Hi DM,

I am getting horrendous download performance with the latest build compared to the version I got a few days ago after you had first updated to the latest httpclient and jdom.  Downloads are not just a bit longer but take ~10 times longer.

Any idea why?  It isn't just the time of day because I did a fast test just 10 mins ago then upgraded my mobile and now the progress bar just crawls from left to right taking ~10 minutes when it used to take  ~1 min.

Also, the Progress message used to say something like "Installing book: <module name>" but now it just says "Install".  Is this my error or JSword's?

Regards
Martin


> Percentage complete during a download should reflect file size
> --------------------------------------------------------------
>
>                 Key: JS-133
>                 URL: http://www.crosswire.org/bugs/browse/JS-133
>             Project: JSword
>          Issue Type: Improvement
>          Components: o.c.common.util, o.c.jsword.book.install
>         Environment: Android
>            Reporter: Martin Denham
>            Assignee: DM Smith
>
> Downloads to a mobile are slower and more variable than to a pc and there can be quite a large difference between predicted download time and actual download time.  Also, the first download does not have a predicted download time and so the first progress bar And Bible showed to users had no percentage complete (maybe this second problem could have been avoided by pre-loading a guesstimate) .
> There is code in JSword to get the download file size (WebResource.getSize()) but the actual download loop does not have access to the Progress object in order to update the percentage so I changed the code to pass the Progress object to the download method. And Bible has been using this for a few weeks now to allow actual download percent to be displayed with no known problems.
> There were a few changes in different classes:
> AbstractSwordInstaller.run() determines if the download times are predicted.  I had to set the last parameter to false to turn predictions off:
>         //change final parameter to false to prevent guessing progress of file download because now actual file size is used
>         Progress job = JobManager.createJob(UserMsg.gettext("Installing book: {0}", sbmd.getName()), predictURI, this, false);
> In HttpSwordInstaller.copy(..) pass the Progress object through to WebResource which actually does the download:
>     private void copy(Progress job, URI uri, URI dest) throws LucidException {
>         if (job != null) {
>             // TRANSLATOR: Progress label for downloading one or more files.
>             job.setSectionName(UserMsg.gettext("Downloading files"));
>         }
>         //MJD START - modified following line - pass job thro to WebResource to allow actual progress indicator
>         WebResource wr = new WebResource(uri, proxyHost, proxyPort, job);
>         wr.copy(dest);
>     }
> The above implies a new constructor was also needed and created for WebResource.
> The WebResource.copy method is where the percent complete is updated currently in And Bible.  It could be argued that this creates inefficiency in a tight loop but the loop isn't that tight because it deals in blocks rather than bytes.  Inefficiency of updating Progress too often was the reason I added progressUpdateCounter so the calls do not happen after every block is fetched, but in reality it did not really save much as anything more than every other time leads to a very jumpy progress bar so I think the progressUpdateCounter part of below could be removed so that the progress is updated every time.
> 95.0% was used below, as in other places to allow 5% for post download operations but I think users expect a delay after download so it could be 100.0%.
> My first attempt involved calling getSize() somewhere after GetMethod and it just hung, hence the comment below.
>     public void copy(URI dest) throws LucidException {
>         InputStream in = null;
>         OutputStream out = null;
>         //MJD START calculate progress as percent of total file size
>         //must call getSize before opening the connection or it hangs
>         int size = getSize();
>         HttpMethod method = new GetMethod(uri.getPath());
>         try {
>             // Execute the method.
>             int status = client.executeMethod(method);
>             if (status == HttpStatus.SC_OK) {
>                 in = method.getResponseBodyAsStream();
>                 // Download the index file
>                 out = NetUtil.getOutputStream(dest);
>                 int progressUpdateCounter = 0;
>                 long totalRead = 0;
>                 byte[] buf = new byte[4096];
>                 int count = in.read(buf);
>                 while (-1 != count) {
>                     out.write(buf, 0, count);
>                     count = in.read(buf);
>                     
>                     totalRead += count;
>                     //update progress occasionally - every other time
>                     if (job!=null && size>0 && progressUpdateCounter++ % 2 == 0) {
>                         int pctRead = (int)((95.0*totalRead)/size);
>                         job.setWork(pctRead);
>                     }
>                 }
>             } else {
>                 // rest is unchanged
> My only reservation is that getSize() may sometimes not work but I have not found any cases where it failed although And Bible only currently downloads from the CrossWire repository.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.crosswire.org/bugs/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira