[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