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

Martin Denham mjdenham at gmail.com
Sat Dec 4 10:17:56 MST 2010


I have reverted to the code I had a couple of days ago and the speed is back
to normal again i.e. ~1 min to download Darby bible compared to >10 min with
the latest code.

It looks like a JSword issue but could be an Android environment issue
because I did see diabolical download performance some months ago due to
configuration.

On 4 December 2010 16:54, Martin Denham (JIRA) <jira at crosswire.org> wrote:

>
>    [
> 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
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20101204/a79edae2/attachment-0001.html>


More information about the jsword-devel mailing list