.. after restarting ktorrent.

Maybe it's mentioned to work like this(?)
But i thought lets report this because it's common not having to restart an application for such setting.

Stoeptegel

That should not happen, I will check it out when I get home.

I'm not seeing it here, if I change it will go to the new limit. No restart necessary.

Really strange, yesterday i had to restart ktorrent to adjust uploadspeed but today after a reboot this just works fine.

Sorry for the timewaste.

Maybe the other peers couldn't download any faster.

I don't think so, because when this occoured i tested it with 5KB/s upload also and this continued uploading at 35KB/s(or 25KB/s, dunno for sure... but the main part is that it reacted like the setting wasn't modified at all).

i have a similar problem:
after some time (about one hour?) ktorrent seems to forget about the upload limit and starts uploading at full bandwidth. if i change the upload settings and press apply it still uploads with full bandwidth.
the only way to get it back to normal seems to be restarting ktorrent. (ktorrent svn)

I had problems with KT not limiting the bandwidth when I was using 1.2rc1. It works fine on the SVN versions I have installed now (about 5 days old). And changing the limits works without a restart of KT for me.

oh.. now that i'm reading my message again:
it is possible for me to change the bandwidth settings and ktorrent adjusts to the new setting. however, once it reaches a certain point and starts to ignore the setting completly, changing the bandwidth settings has no effect. i'll have a look at the code later today, but i'm not sure if i'll be able to find the root of the problem

Weird problem, it can just forget about the limit.

It's weird indeed but correct. I had it 2 minutes ago after a day runtime; it just filled the upload bandwidth bittornado left over.

i actived logging of the nb variable in uploadcap.cpp

seems that here's the problem.
when everything is normal, nb usually is 512, sometimes a little more, sometimes a little less.

then, somehow (i somehow failed to notice how this happened, will start ktorrent again and log everything to a file), nb is really high:
nb = 512521630
nb = 512505752
nb = 512489818

Uint32 nb = (Uint32)floor((el / 1000.0) * max_bytes_per_sec) + leftover;

think i found the reason.

since the timer takes the system time, and my system time gets updated every hour (rdate) the time getElapsedSinceUpdate call might return a negative value (my hardware clock seems to run a little fast).


double el = timer.getElapsedSinceUpdate();
Uint32 nb = (Uint32)floor((el / 1000.0) * max_bytes_per_sec) + leftover;

so i just checked by setting my system time to one minute back, and immediately the download got borked. the nb variable overflowed

a fix would probably be, to make sure that el never gets negative.

We have stopped printing nb for a while now, so you should update to the latest (which will be 1.2 in a few hours)

i reenabled it in my current build.

the problem is in your Timer class.

Uint32 Timer::getElapsedSinceUpdate() const
{
QTime now = QTime::currentTime();
return last.msecsTo(now);
}


so, Qtime.msecsTo() returns an int. not an unsigned.
When I change my system time to somewhen earlier, last.msecsTo(now) is negative which therefor overflows when it is converted to Uint32.

Actually I don't seem to understand, why it is so necessary to calculate the exact time. Your update timer fires every 100msecs. On my system,
double el = timer.getElapsedSinceUpdate(); is always around 100 msecs, ok, sometimes it's 96, sometimes it's 103. so why not just take the timer signal? if let's they some realtime mode process was starting to crunsh numbers and ktorrent and qtimer wouldn't be running for 30 seconds, and somone leeching from me, wouldn't be getting any packets, so be it. With the current system he would get maximum bandwidth when ktorrent finally gets the cpu again, while with just qtimer he would get the normal bandwidth..
not sure if I made it clear..