[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:42:56 MST 2010
I don't think so. The code I was using before, which was fast, updated the
Progress after every block fetch in the inner loop in WebResource.copy().
On 4 December 2010 17:24, DM Smith <dmsmith at crosswire.org> wrote:
> Wild guess: it updates progress too often.
>
> Cent from my fone so theer mite be tipos. ;)
>
> On Dec 4, 2010, at 12:17 PM, Martin Denham <mjdenham at gmail.com> wrote:
>
> 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>
> 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>
>> 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>
>> 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>
>> http://www.crosswire.org/bugs/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> <http://www.atlassian.com/software/jira>
>> http://www.atlassian.com/software/jira
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> <jsword-devel at crosswire.org>jsword-devel at crosswire.org
>> <http://www.crosswire.org/mailman/listinfo/jsword-devel>
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
> _______________________________________________
> 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/29bc9217/attachment-0001.html>
More information about the jsword-devel
mailing list