Bug in trunk peer_connection::second_tick 4615

[GoogleCodeExporter]

...
if ((warning & (1 << channel)) == 0) return;
...
prevents m_statistics.second_tick() from beeing called.

Actually, there is more than one _return_ before the call to 
m_statistics.second_tick() but those do not seem important cases.

I think that _return_ should be _continue_?

The resulting behavior could explain the problem of the negative bandwith 
quotas because the counters for this peer would not get reseted.

MassaRoddel

Original issue reported on code.google.com by webmas...@massaroddel.de on 20 Sep 2014 at 1:15

[GoogleCodeExporter]

thanks!

Original comment by arvid.no...@gmail.com on 20 Sep 2014 at 11:58

• Changed state: Fixed