Beware - ktorrent 3.2.1 is seriously flawed!

When you click “remove” on a finished AND stopped torrent, it automatically deletes the downloaded data!

An extremely annoying and rather stupid default, especially as no warning is given that it is about to delete everything that you just downloaded!

The “normal” function of the remove button has always been to remove the torrent from the download/seed list, it never deleted anything before.

I have had varied success with ktorrent for quite a few versions. Sometimes it is brilliant, next upgrade it is hopeless. I changed to Deluge, and haven’t looked back.

get Vuze :stuck_out_tongue:

I never encountered such behaviour, weird. Every time i click remove it only removes torrent files which i store at .kde4/share/apps/ktorrent

Vuze for me too. It’s seems to allow better surfing whilst running compared to KT.

While i never had problem with both ktorrent or Vuze i noticed that Vuze is a leech for memory :slight_smile:

While ktorrent takes about 25MB now Vuze topped up at 500MB :slight_smile:

P.S. Isn’t browsing the web while torrenting only a matter of proper settings??

Just tested and didn’t delete anything except the listing in ktorrent

Geoff

Just tested with a fully downloaded file and it only removed the torrent but left the data. I also tried it out with an incomplete download. It asked if I wanted to delete the data or keep it. So I guess this is the closest thing I could get to your problem. Even then it asked first.

Ian

@BenderBendingRodriguez

Vuze topped up at 500MB

Crumbs, that’s ridiculous! Something amiss there.

@growbag:
Maybe something got tripped up on installation. Did you compile it yourself?

Well that was maximum it ever had, normally it fluctuates at around 300~400MB

But as everyone can see it’s turning into a BIG FAT cow (because it’s JAVA?), it’s not a simple torrent client anymore :slight_smile:

I’ve never had good luck with KTorrent. Mostly, it crashed before the download was done. Vuze always worked much better for me and the download speeds were faster.

I tried to recreate the situation but can’t seem to.

So either it had something to do with the fact that I had just ran a zypper up and it had installed a new version of ktorrent while the old version was still running (which indeed it did), made something go temporarily insane, or I inadvertently deleted the files myself without realising it.

Although I would swear on my Father’s grave that I never did such a thing, my short term memory is a bit dodgy at the best of times!

My Grandfather had Alzheimer’s, maybe it’s the early onset of that! :.

Only starting Vuze, without any torrent, I get it consumes 96MiB of physical memory, being 18MiB shareable.

KTorrent, after hours of running, with two torrent that sum more than 10GiB is consuming 48MiB, being 25MiB shareable. And in this case the shareable memory is more probable to be really shared since I run KDE.

Running Vuze 4.2.0.2 from home:RedDwarf:java:nobuild (compiled from source and heavily patched to remove Windows/Mac parts) and Ktorrent from a self compiled RPM (the one from KDE:KDE4:Factory:Desktop compiled against KDE:42 with DHT and all search sources enabled).

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2870 root 20 0 267m 79m 3776 S 3 4.0 46:49.97 Xorg
4742 me 20 0 694m 41m 15m S 2 2.1 28:52.25 plasma
8756 me 20 0 410m 37m 26m S 1 1.9 5:30.01 ktorrent

That’s quite amusing because my swap partition is only 196 megs in size! No idea how these apps are using so much non-existent swap :sarcastic:.

Don’t even try to understand those numbers. VIRT includes a lot of things (see pmap output).
With 1GiB of RAM I usually don’ use swap at all. So RES is a good measure of memory usage (but you have to think that the SHR part of RES can be shared by other processes… but is only really shared if there are other processes interested in it).
So… your KTorrent is using at least 11MiB of RAM only for its own use, but is also using another 26MiB that can be shared wit other processes (and since it’s a KDE app a lot of these 26MiB will be KDE libs… if you use KDE these 26MiB can be shared by a lot of apps). It would still have to be seen how many memory from KTorrent is swapped, that should be added.

I’m using KTorrent for almost a year now, and haven’t encountered any problems so far :slight_smile:

KTorrent works fine here, and I would never want to use another client except for rtorrent on a CLI-only system.
It has good features, integrates well with KDE and reaches very good speeds (the calculation of recommended network settings does a great job there).

Somebody asked me that question earlier, and I forgot to answer, apologies there!

No, it was the standard version found in the KDE4.2 repo at the time.

I try not to have self-compiled apps because it confuses things if/when I come to re-install, update/upggrade, or do a fresh installation.

That’s just my preference, and is not everyone’s idea of how I should do it, but nonetheless that’s my philosophy ;).

I did run zypper up and it did download and install an updated version of Ktorrent while the old Ktorrent was still running. That might have been the problem, or as I now believe, it was simply my own absent-mindedness.

I do a lot of silly things, like forgetting where I put my keys, losing things that I just had in my hand a second before, and forgetting how to breathe etc’ rotfl!.

Comes with old age I believe :shame:.

In my experience those crashes occur when there are too many connections open at once. But it’s not ktorrent that crashes, but the internet connection that “freezes” - the ACT lights on modem either go off or stay on, instead of blinking.

If I limit the number of max and per-torrent connections (and restart the modem) the problem goes away. My current set-up is 240 (global) and 140 (per torrent) max connections.

For better downloads I have to limit the upload speed, as it’s an asymmetric line (up speed is about 1/3 of down). If there are enough seeds, the download speed tops at the ISP max.