Description:
------------
From APC-3.1.4/apc_rfc1867.c:
        case MULTIPART_EVENT_START:
            {
                multipart_event_start *data = (multipart_event_start *) event_d
ata;

                RFC1867_DATA(content_length)    = data->content_length;
                RFC1867_DATA(tracking_key)[0]   = '\0';
                RFC1867_DATA(name)[0]           = '\0';
                RFC1867_DATA(cancel_upload)     = 0;
                RFC1867_DATA(temp_filename)     = NULL;
                RFC1867_DATA(filename)[0]       = '\0';
                RFC1867_DATA(key_length)        = 0;
                RFC1867_DATA(start_time)        = my_time();
                RFC1867_DATA(bytes_processed)   = 0;
                RFC1867_DATA(rate)              = 0;
                RFC1867_DATA(update_freq)       = (int) APCG(rfc1867_freq);
                RFC1867_DATA(started)           = 0;

                if(RFC1867_DATA(update_freq) < 0) {  // frequency is a percenta
ge, not bytes
                    RFC1867_DATA(update_freq) = (int) (RFC1867_DATA(content_len
gth) * APCG(rfc1867_freq) / 100);
                }
            }
            break;

Notice that RFC1867_DATA(prev_bytes_processed) isn't set to 0. This means that the small array representing upload progress (stored in APC) may not get updated because the following condition evaluates to false:
                if(RFC1867_DATA(bytes_processed) - RFC1867_DATA(prev_bytes_processed) > (uint) RFC1867_DATA(update_freq)) {


The end result is that sometimes user may not see the progress bar moving. For example, if the previous uploaded file resulted in a large value of RFC1867_DATA(prev_bytes_processed).