Created attachment 9689 [details]
suggested patch

I actually posted about the same a while back on the list, but was't sure if it was expected behaviour (I would think not), or a bug. I made a patch which appears to fix this issue for most of my use cases and have been using this for a while now. From what I've seen this should fix bug 10451 as well.

(In reply to comment #0)
>Percentage get's updated only after file has been transferred to destination.
From what I noticed as well as looking the code, I think the percentage get's updated *before* the file even gets transferred , hence leading rsync to think that a huge file has been transferred instantaneously showing very huge unrealistic bandwidths. There after no more bytes transferred changes till the next file, causing speed to decay down again.

Thanks.. I will try it out.

(In reply to comment #1)
> Created attachment 9689 [details]
> suggested patch
> 
> I actually posted about the same a while back on the list, but was't sure if it
> was expected behaviour (I would think not), or a bug. I made a patch which
> appears to fix this issue for most of my use cases and have been using this for
> a while now. From what I've seen this should fix bug 10451 as well.

Yes it works perfectly. Thanks a lot.. Also speed is correct as well (it settles to correct value)

Have a nice day

(In reply to comment #3)
> Thanks.. I will try it out.
> 
> (In reply to comment #1)
> > Created attachment 9689 [details] [details]
> > suggested patch
> > 
> > I actually posted about the same a while back on the list, but was't sure if it
> > was expected behaviour (I would think not), or a bug. I made a patch which
> > appears to fix this issue for most of my use cases and have been using this for
> > a while now. From what I've seen this should fix bug 10451 as well.

Thanks for the patch!  I think this makes the output much nicer.  I have applied it in the git repo for the next release.