Incorrect values for bytesTotal in PROGRESS events

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start several image and/or swf loads at the same time
2. Subscribe to the BulkProgressEvent.PROGRESS event
3. Watch the values of bytesTotal when loading over a slow connection

What is the expected output? What do you see instead?
The bytesTotal value may be incorrect (low) at first which causes my
progress bar to "jump" backward once the correct value is known.

What version of the product are you using? On what operating system?
Rev 246.  Windows Vista.

Please provide any additional information below.
It looks like the getProgressForItems() function sets bytesTotal to
infinity if all file sizes aren't known which is a good thing, however it
doesn't take into account the fact that Loaders may report a value of -1
for bytesTotal even after their OPEN event has fired.

Original issue reported on code.google.com by ryan%rph...@gtempaccount.com on 30 Dec 2008 at 4:20

[GoogleCodeExporter]

Hi Ryan.

Maybe this is just an artifact for bytesTotal being utterly unreliable untill 
all requests have a lenght header.
This is explained better here:
http://code.google.com/p/bulk-loader/wiki/ReportingLoadingProgress

The short story is that when loading more items than the connections you have 
open, you need to use 
weighted progress, as that will allow for a much better reading.

I am closing this as invalid, since I can't find any solutions to solve this, 
but I am very open to working code to 
fix this.

Cheers
Arthur Debert

Original comment by debert on 18 Jan 2009 at 3:26

• Changed state: Invalid

[GoogleCodeExporter]

What I did was change line in BulkLoader.getProgressForItems from

if (item.status == LoadingItem.STATUS_STARTED || item.status ==
LoadingItem.STATUS_FINISHED || item.status == LoadingItem.STATUS_STOPPED){

to

if (item.status != LoadingItem.STATUS_ERROR && item.bytesTotal > -1){

This delays computation of bytesTotal a little longer until all items are 
reporting
the correct number.  

Here's an example:  let's say you have two items that are 1024 bytes each.  
Currently
it is possible for one or both of them to initially report -1 for bytesTotal 
which
means bulk loader will report POSITIVE_INFINITY at first... then -2, 1023, or 
2048
which can cause some odd behavior (and it may behave differently every time you 
run it).

My suggestion ensures that it will go straight from POSITIVE_INFINITY to 2048.  
It
may sit at POSITIVE_INFINITY for a few frames longer than before, but at least 
it
prevents the quirky behavior.

Thanks for the heads up on the weighted progress though, that will be very 
useful for
future projects.

Original comment by ryan%rph...@gtempaccount.com on 21 Jan 2009 at 2:56