Hello all,

Recently installed ktorrent, must say I like the look and feel of it, however I have noticed some problems

First - versions

Gentoo Linux
KDE 3.3
KTorrent 1.2rc1 - As per the Gentoo ebuild system installed January 7

1) Memory usage

This just seems to grow and grow, I have 256MB RAM and 1GB Swap, for the first 2-3 hours kTorrent sits on using about 20-30MB, then all of a sudden grows to use > 150MB, continuously swaps and will not die when the File->Quit option is chosen. It just sits there and I have to kill from the command line.

2) Slow downloads, fast uploads

I have connected to torrents with about 100 peers and about 30 seeders on my 512/128 ADSL connection. With or without upload limiting I am averaging uploads at about 15KB/s while downloads hover at an average of 1KB/s (Ports are forwarded and not blocked). While I am happy to share, my understanding of the protocol is that I should have uploaded about the same amount as I have downloaded. Also this is occuring with any torrents I try, I can't get any performance, nobody wants to send me anything. Even more bizarre, I have about 1% of the torrent and am uploading at ~15KB/s to peers with >80% and they never send anything back...

3) Upload capping

Doesn't seem to work, whether capped at 10KB/s or 6KB/s, my upload average always seems to be 15KB/s

4) Port freeing

When I quit ktorrent (because memory usageis rising) I often have to wait about 5-10 minutes before restarting it because all the sockets are still open. Why aren't the sockets properly closed when the application exits?

Thanks again for reading this far I rather like the application but find it a bit difficult to use at the momer due to both its slowness and habit of dying after running for 2-3 hours. This means I can't really run overnight, nor can I leave it on without continuously running into the room to check progress and stop/restart ktorrent

Any help would be appreciated...

One more question, has anyone here thought of building a torrent proxy type system? I have a server which is on 24/7 and would find an torrent client/server system really useful. The client would run on my desktop machine and open the torrent file and send it to the server (which runs 24/7) for download. The client app can then talk to the server to find and display the progress of the torrent. Also I can switch off my desktop while the server continues to get the file, I can switch on tomorrow to recheck progress. I would find this to be useful as I only have to configure torrent for one machine on the network and only open ports up for one box.

Or perhaps I am the only person wanting something like this

Jason[/b]

Some comments to your list:

>1) Memory usage
This has become much better post rc1, you should perhaps try a newer SVN version. Perhaps time for a rc2 soon?

>3) Upload capping
Seems like there still are some problems there, have not investigated it to much. But it looks like it don't work with freshly compiled SVN revision 496667.

And few additional points:
- When pressing Apply in the config dialog(after changing upload capping) all torrents get stopped. (same for queue manager).

- Small error in plugins/infowidget/infowidgetbase.ui near the end, in the includehints section:
<includehints>
<includehint>kt::downloadedchunkbar.h</includehint>
<includehint>kt::availabilitychunkbar.h</includehint>
<includehint>klistview.h</includehint>
</includehints>

The kt:: should not be there, makes compile fail for some(me).

- The colorization of share ratio is nice, but I think you should keep >1 black. Green on the the colors usually used for that widget(window backround) are slightly straining on the eye, and don't really give any added benefit from black. If you are low on sharing it's red, otherwise it does not really matter....
Edit: Or it should be. Now I see it stays green for a torrent when the sharing drops below 1 too, that cant be right?

- When pressing Apply in the config dialog(after changing upload capping) all torrents get stopped. (same for queue manager).

This should not happen. After Config::Apply() and QueueManager::Apply() we sort downloads in queue and start the ones that should run. Apparently there's some kind of bug there. Can you tell me the following:
- MaxDownloads value (from config)
- How many torrents are running at the moment (how many seeding/downloading)
- How many are user controlled and how many are QM controlled

Any additional info would be helpfull, too.

The colorization of share ratio is nice, but I think you should keep >1 black. Green on the the colors usually used for that widget(window backround) are slightly straining on the eye, and don't really give any added benefit from black. If you are low on sharing it's red, otherwise it does not really matter....
Edit: Or it should be. Now I see it stays green for a torrent when the sharing drops below 1 too, that cant be right?

Text is colorized red when ratio is below 80%. I chose this value since most trackers reffer to it as a 'optimal share ratio'. Everything above 80% is colorized green. I don't mind changing the colors if anyone should have a nice suggestion.

Apparently there's some kind of bug there.
That was my guess too:-)

- MaxDownloads value (from config)
0, no limit.

- How many torrents are running at the moment (how many seeding/downloading)[i]
only 3 downloading, 2 stopped/not started(1 is complete).

[i]- How many are user controlled and how many are QM controlled
None, all are user contolled, if I switch all to QM they all get stopped when hitting apply.

Any additional info would be helpfull, too.
I think it's somehow related with the QM, since I had been playing with the QM before I noticed it.
Try this, open QM and set a couple of torrent to be QMed and apply(they should now stop). Manually start them and switch the QM to user and apply(if they stop again, start them). Open config and just press Apply, for me they now stop again.


Text is colorized red when ratio is below 80%. I chose this value since most trackers reffer to it as a 'optimal share ratio'.
Ok, thought it was 100%, 80% explains it. I have one torrent who have dropped below 80 during the night and it's changed to red, so I guess it's ok after all:-)

I don't mind changing the colors if anyone should have a nice suggestion.
It's probably just me(green on top of the backround color I use was slightly distracting:-), as long as it plays fairly well with different color schemes it's not really important:-) Personally I think using both green and red are a little 'too much', but I'll prefer the decision be made by someone with sense of aesthetics and 100% color vision(eg, anyone but me:-)

It's 100% QM related. We added this feature after rc1 release so not many people could test it so far. We need as much as possible tests on QM to get it stable enough for final 1.2 release, so thanks for pointing out your problem. I'm on it...

It's probably just me(green on top of the backround color I use was slightly distracting:-), as long as it plays fairly well with different color schemes it's not really important:-) Personally I think using both green and red are a little 'too much', but I'll prefer the decision be made by someone with sense of aesthetics and 100% color vision(eg, anyone but me:-)

I think red is OK. Green is, indeed, a little 'too much' light so we may want to make it a bit darker. But, offcourse, this is really ungrateful job to make it look good with different color schemes so as far as we don't hear many users complaining - we're good

Well I have had some (minimal) success in making things more useable.

When ktorrent was initially installed on my system the default value for the maximum number of connections per download was 120. I lowered this value to 40 and achieved the following:

1) Average Download speed increased from 1KB/s to 4.5KB/s - Woohoo

2) Time between running out of memory (process size >= 150MB) increased from 2-3 hours to about 12 hours.

The first point means my downloads now run four times as quickly (but I would still have hoped for more on a 512kbps (64KB/s) link. The second means that I can now use ktorrent overnight as I only need to stop and restart it twice a day instead of repeatedly.

This still suggests a memory leak somewhere and it looks as though resources allocated to connections are not being properly released when a connection is closed, obviously the problem is exarcerbated with an increased number of concurrent connections which are continuously opened and closed.

However the same problems exist with quiting when memory is exhausted, upload capping, and properly freeing the ports upon application shutdown.

Concerning the memory leaks, can you install a version compiled like this :

./configure --enable-memleak-check --enable-debug=full
make
make install

Then run ktorrent from a shell :
ktorrent
That should produce a file named leak.out

Then run the following script :
http://ktorrent.pwsp.net/downloads/leak-analyze

like this :
./leak-analyze /path/to/ktorrent/binary leak.out

That will print out a list of memory leaks and where they are located.

I may get around to that as soon as the torrent I am trying to download completes, I don't want to stuff it up half way through

Another note, I previously noted that by decreasing the maximum connections from 120 to 40 I managed to go to ~4KB/s download and longer time between memory exhaustion. I just tried decreasing the number to 35 (after seeing some ATM VC Congested warnings in my DSL modem log) and lo and behold, within five minutes of decreasing the maximum number of connections I was seeing an average download rate of 15-20KB/s, another 4-5 fold increase.

It seems that some of my problems may be network related, I will have to get around to properly installing both priority queueing and rate limiting on my gateway/server/firewall box to relieve some of the stress on my modem.

However the memory leak still appears to be there and I will help to try to track it down once this torrent will eventually complete, however this will take a while at 5GB