The best I can describe it is, ktorrent will download and or upload for 2 or 3 seconds at high (ish) speed, then appear to stop for more than 10, even though some data seems to be transfered according to my bw meter, just not as fast. But Ktorrent shows all torrents as stalled for that time. Its really odd, and annoying. It's making torrents take longer to download and seed than they should.

I'm also getting some crashes now and then. Enough that I created a cron job to auto launch ktorrent if its crashed. I'm not certain if its due to bad hardware or not.

edit, also my bandwidth meter seems to be regestering 2x the upload cap I have set. I have ktorrent set to 30KB/s, and the meter registers 60KB/s+, I have no other transfers going when I see this, so its gotta be ktorrent. also, both up+down on the meter shrink to 3 digit Byte/s counts when KT is exited.

Tomasu wrote:The best I can describe it is, ktorrent will download and or upload for 2 or 3 seconds at high (ish) speed, then appear to stop for more than 10, even though some data seems to be transfered according to my bw meter, just not as fast. But Ktorrent shows all torrents as stalled for that time. Its really odd, and annoying. It's making torrents take longer to download and seed than they should.

I came here only to confirm this issues
Many polish (I'm from Poland) linux users on many polish linux forums are saying that "Ktorrent is nice but many times downloading just stops so use XYZ, ZXY"

Maybe developer of Ktorrent during refactoring for KDE4 could also rewrite downlading/uplading functions?

greetings

I think you or your country mates are using an older ktorrent. I haven't seen that bug in a long time. What I was seeing was all my torrents would burst for N seconds at high speeds, and then stall for a bout 10 times as long, and repeat that now and again.

I have a feeling my issue was/is due to my system, since its so far been impossible to debug and diagnose.

I suggest you should upgrade to the absolute latest ktorrent, and you'll find ktorrent will happily work just about as well as utorrent.

Code: Select all

nano /var/log/packages/ktorrent-2.0.3-i686-1Drak


latest stable AFAIK ... 2.1 is stil "rc" ... but if in 2.1 it is gone that's great news.

So hopefully Ktorrent2.1 will be in repo when it is marked as stable.

thx for tip

es, there are many speed improvements after v2.0.3 so you should definitely upgrade. Stable v2.1 should be out pretty soon.

@Tomasu: Your problem is odd, indeed. Does it happen with all torrents? What about private trackers torrents? Those should definitely download without this problem.

Most of my torrents are private tracker, and to be honest, most of the non private tracker torrents work MUCH better. Maybe it has something to do with demonoid itself, I don't know.

Its weird, even my upload stops totally. Its a really odd problem, and I'm not sure whats even wrong.

Demonoid torrents are more/less slow for me too. Seeing that Demonoid torrents are public (you can download them even though you're not a member) maybe you should try some private tracker that has high ratio requirements. Those trackers give abnormal download speeds. Just to make sure everything's OK with your KT...

It's not the speed, some torrents are speedy and download right away.

Its how sometimes, ALL of my loaded torrents (from different trackers) will stop all uploading and downloading simultaneously, and stay that way for a while, and then all start back up again later for a few seconds and then stall again for a long time.

I can't tell if this is really a ktorrent problem or not.

I have a little more info now, it seems ktorrent is having problems with downloading /FAST/. And by fast, I mean on the order of 500KB/s to 1.12MB/s. It seems to start eating up large amounts of CPU, and then crash. It doesn't crash all the time, when it doesn't, it just stops transferring anything for a good long time.

Even more now, I've tried limiting ktorrent's bandwidth usage (via its own settings), down to 300KB/s, and it won't respect it, it'll get up to around 700KB/s, freeze, then crash. (medium or low mem usage setting, I'll try high next)

edit, ok, tested, and its crashed even faster this time.

edit2: Setting the download bw limit to 0 causes an immediate crash. setting downloadBandwidth in the config to "nothing" aka "empty" makes ktorrent use a default of 500. I'm trying with a setting of 5000 now to see what happens.

edit2: Setting the download bw limit to 0 causes an immediate crash. setting downloadBandwidth in the config to "nothing" aka "empty" makes ktorrent use a default of 500. I'm trying with a setting of 5000 now to see what happens.

That's not the download speed limiter, that is the available bandwith so that we can draw the speed bars in the system tray icon.

And it does crash when it is set to 0, it seems somebody forgot to check for a division by zero.

That's not the download speed limiter, that is the available bandwith so that we can draw the speed bars in the system tray icon.

OOps. I _knew_ there was a second entry there some where.. I'll go and retest this again once it starts crashing again.

edit: Thats not to discount the abnormal CPU usage when downloading fairly quickly, then the crash shortly after.

Allright, I have a backtrace to show this time:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x6ecf7bc2 in std::_Rb_tree_increment () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
(gdb) bt
#0  0x6ecf7bc2 in std::_Rb_tree_increment () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
#1  0x6ecf7c1d in std::_Rb_tree_increment () from /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
#2  0x6fdf9002 in std::_Rb_tree_const_iterator<bt::AuthenticateBase*>::operator++ (this=0x778846d0)
    at /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4/bits/stl_tree.h:265
#3  0x6fdf8143 in bt::AuthenticationMonitor::update (this=0x80f2558) at authenticationmonitor.cpp:106
#4  0x08081a2b in KTorrentCore::update (this=0x82f4fc8) at ktorrentcore.cpp:564
#5  0x080840e1 in KTorrentCore::qt_invoke (this=0x82f4fc8, _id=5, _o=0x77884828) at ktorrentcore.moc:243
#6  0x6f004b19 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#7  0x6f00576d in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#8  0x6f33f5e9 in QTimer::timeout () from /usr/qt/3/lib/libqt-mt.so.3
#9  0x6f0282cf in QTimer::event () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x6efa5947 in QApplication::internalNotify () from /usr/qt/3/lib/libqt-mt.so.3
#11 0x6efa6501 in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#12 0x6f5253ba in KApplication::notify () from /usr/kde/3.5/lib/libkdecore.so.4
#13 0x77884d00 in ?? ()
#14 0x082f4ffc in ?? ()
#15 0x77884ad4 in ?? ()
#16 0x77884a08 in ?? ()
#17 0x6ebe0c6f in malloc () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I'll run it a few more times under gdb and see if the crashes are comming from this one place.

edit, Yup, getting repeatable crashes at the same point.

It crashes while iterating over a std::set, the question is why ? And why am I not seeing this ?

I'm not seeing this either.