A few bug reports, all in latest svn. I'll gather more details if needed, but I've reproduced them, so you should be able to as well. I haven't had time to look into the code and find the problems myself.

1. This is a crash bug, If you select multiple torrents and choose "Remove Torrent and Data" from the right click menu, ktorrent crashes with "Invalid List Index" or something similar.

2. Several times I've used the "Move Data" feature on a multi-file torrent that's being seeded, and later the torrent will stop with an Error that it can't find some file, and will list a file at the old location. So somewhere the location of the files is not being correctly updated. Starting the torrent again causes it to work fine, so somehow the error stopping the torrent actually fixes the problem. As far as I can tell this is multi-file torrent only.

3. Pretty frequently (several times per download) chunks get stuck. What I mean by this is that they have an assigned peer, but that peer is not sending any data. Because that chunk has an assigned peer, it does not get picked to have another peer assigned and won't finish until there are no more chunks left with no assigned peers. This causes two problems in general: more chunks being open than need to be, and chunks being available for upload later.

For me, it causes an additional problem. I have changed ktorrent's chunk selection method to prefer earlier chunks in the torrent. This allows me to start watching a video before it has completed downloading, but only once I solved this problem. My solution is a bad hack; I haven't had a chance to fix this correctly.

Let me know if you need more info or better description; I may have a chance to take a look at these myself (especially the last one) on Sunday.

phantom042 wrote:A few bug reports, all in latest svn. I'll gather more details if needed, but I've reproduced them, so you should be able to as well. I haven't had time to look into the code and find the problems myself.

1. This is a crash bug, If you select multiple torrents and choose "Remove Torrent and Data" from the right click menu, ktorrent crashes with "Invalid List Index" or something similar.

Got a backtrace ?

2. Several times I've used the "Move Data" feature on a multi-file torrent that's being seeded, and later the torrent will stop with an Error that it can't find some file, and will list a file at the old location. So somewhere the location of the files is not being correctly updated. Starting the torrent again causes it to work fine, so somehow the error stopping the torrent actually fixes the problem. As far as I can tell this is multi-file torrent only.

This is a known issue :
http://bugs.kde.org/show_bug.cgi?id=158813

I'm looking for a solution at the moment

3. Pretty frequently (several times per download) chunks get stuck. What I mean by this is that they have an assigned peer, but that peer is not sending any data. Because that chunk has an assigned peer, it does not get picked to have another peer assigned and won't finish until there are no more chunks left with no assigned peers. This causes two problems in general: more chunks being open than need to be, and chunks being available for upload later.

For me, it causes an additional problem. I have changed ktorrent's chunk selection method to prefer earlier chunks in the torrent. This allows me to start watching a video before it has completed downloading, but only once I solved this problem. My solution is a bad hack; I haven't had a chance to fix this correctly.

This is not a bug, the bittorrent protocol is not designed to be used as a streaming media protocol. So KTorrent is not designed to be used as a streaming media app.

However if you are looking for a workaround, you could play around with the chunk priorities. The chunk selection algorithm in 3.0.0 is a lot stricter on priorities.

The chunk selector used to select the highest priority chunk which is not being downloaded. Now it first finds this chunk and then it goes back to see if there are higher priority chunks, and it selects the one with the least peers of the higher priority chunks.

So you could progressively increase the priority of the next couple of chunks. So you start at 0, and you set the priority of the first 5 or so as high, when the first one is downloaded, you make the 6th one also high priority. And so you move on until you have all the chunks of the movie.

Note: this will lead to more useless pieces being downloaded.

phantom042 wrote:1. This is a crash bug, If you select multiple torrents and choose "Remove Torrent and Data" from the right click menu, ktorrent crashes with "Invalid List Index" or something similar.

This doesn't happen to me.
I tried selecting only 2 torrents tho...

This is not a bug, the bittorrent protocol is not designed to be used as a streaming media protocol. So KTorrent is not designed to be used as a streaming media app.

However if you are looking for a workaround, you could play around with the chunk priorities. The chunk selection algorithm in 3.0.0 is a lot stricter on priorities.

The chunk selector used to select the highest priority chunk which is not being downloaded. Now it first finds this chunk and then it goes back to see if there are higher priority chunks, and it selects the one with the least peers of the higher priority chunks.

So you could progressively increase the priority of the next couple of chunks. So you start at 0, and you set the priority of the first 5 or so as high, when the first one is downloaded, you make the 6th one also high priority. And so you move on until you have all the chunks of the movie.

Note: this will lead to more useless pieces being downloaded.

If you just ignore what I said about my modification, I still think this is a bug. Those connections should be killed if they aren't sending any data for that long... don't know why they aren't. Not having those chunks complete does mean you have less chunks available for upload early in the download. It also does mean that more chunks have to stay in memory.

I was able to work around this for my own purposes, but the solution I used isn't the "right" solution. I basically just made ktorrent always prefer to assign a peer to a chunk that is partially completed and has a d/l speed of zero.

I don't have a backtrace for the first / crash bug. I just tried to reproduce it and couldn't, though it's happened to me twice before. The only difference between what I just tried and before was that those torrents were downloading and these were seeding. I'll let you know if I can get one.

Code: Select all

Index: ktorrent/libbtcore/download/chunkdownload.cpp
===================================================================
--- ktorrent/libbtcore/download/chunkdownload.cpp   (revision 783374)
+++ ktorrent/libbtcore/download/chunkdownload.cpp   (working copy)
@@ -251,6 +251,9 @@
       // go over all PD's and do requets again
       foreach (PieceDownloader* pd,pdown)
          sendRequests(pd);
+
+      if(getDownloadSpeed() == 0 && getNumDownloaders() > 0)
+         releaseAllPDs();
    }
    
    


This seems to stop chunks from getting stalled with piece downloaders assigned but with no data being received.

phantom042 wrote:

Code: Select all

Index: ktorrent/libbtcore/download/chunkdownload.cpp
===================================================================
--- ktorrent/libbtcore/download/chunkdownload.cpp   (revision 783374)
+++ ktorrent/libbtcore/download/chunkdownload.cpp   (working copy)
@@ -251,6 +251,9 @@
       // go over all PD's and do requets again
       foreach (PieceDownloader* pd,pdown)
          sendRequests(pd);
+
+      if(getDownloadSpeed() == 0 && getNumDownloaders() > 0)
+         releaseAllPDs();
    }
    
    


This seems to stop chunks from getting stalled with piece downloaders assigned but with no data being received.

And it is a very crude way of doing this, every time a peer is a bit slow with starting to send data you will release it.

I am now able to reproduce the crash when multiple torrents are selected and "Remove Torrent" is clicked in the context menu. This time, I was not doing "Remove Torrent + Data" so that is not necessary for the error to occur, but it can happen then as well. The torrents were all in the "Downloaded" state this time, so it's happened with downloading, seeding, and downloaded torrents. I also believe it's happened now with two, three, and five torrents selected.

When I start ktorrent again, the torrents are still in the list, and repeating causes the crash again. I'll leave KTorrent in this state for now in case you want me to do anything else.

First crash:

Code: Select all

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb57fb720 (LWP 20521)]
[New Thread 0xb355eb90 (LWP 20538)]
[New Thread 0xb3d5fb90 (LWP 20537)]
0xb7fcc410 in __kernel_vsyscall ()
[Current thread is 0 (LWP 20521)]

Thread 3 (Thread 0xb3d5fb90 (LWP 20537)):
#0  0xb7fcc410 in __kernel_vsyscall ()
#1  0xb638eaf7 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb6c45a74 in net::DownloadThread::update (this=0x80ead00)
    at /home/adam/ktorrent/libbtcore/net/downloadthread.cpp:50
#3  0xb6c45ef8 in net::NetworkThread::run (this=0x80ead00)
    at /home/adam/ktorrent/libbtcore/net/networkthread.cpp:48
#4  0xb7dfc057 in ?? () from /usr/lib/libQtCore.so.4
#5  0x080ead00 in ?? ()
#6  0x00000000 in ?? ()

Thread 2 (Thread 0xb355eb90 (LWP 20538)):
#0  0xb7fcc410 in __kernel_vsyscall ()
#1  0xb7dacaa5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7dfc924 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#3  0xb6c456fd in net::UploadThread::update (this=0x80eaf10)
    at /home/adam/ktorrent/libbtcore/net/uploadthread.cpp:73
#4  0xb6c45ef8 in net::NetworkThread::run (this=0x80eaf10)
    at /home/adam/ktorrent/libbtcore/net/networkthread.cpp:48
#5  0xb7dfc057 in ?? () from /usr/lib/libQtCore.so.4
#6  0x080eaf10 in ?? ()
#7  0x00000000 in ?? ()

Thread 1 (Thread 0xb57fb720 (LWP 20521)):
#0  0xb7fcc410 in __kernel_vsyscall ()
#1  0xb6357ba6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb63579b7 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7245000 in ?? () from /usr/lib/kde4/lib/libkdeui.so.5
#4  0x00000001 in ?? ()
#5  0x00000002 in ?? ()
#6  0x08117218 in ?? ()
#7  0xbfbaca8e in ?? ()
#8  0xbfbaca8e in ?? ()
#9  0xbfbaeaf8 in ?? ()
#10 0x00000003 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
#0  0xb7fcc410 in __kernel_vsyscall ()


The next two crashes were essentially identical, with this being from the second crash.

In terminal:

Code: Select all

ASSERT failure in QList<T>::operator[]: "index out of range", file /usr/include/qt4/QtCore/qlist.h, line 399
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = ktorrent path = <unknown> pid = 3852
sock_file=/home/adam/.kde4/socket-adam-laptop/kdeinit4__0

Backtrace:

Code: Select all

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb571f720 (LWP 3792)]
0xb7ef0410 in __kernel_vsyscall ()
[Current thread is 0 (process 3792)]

Thread 1 (Thread 0xb571f720 (LWP 3792)):
#0  0xb7ef0410 in __kernel_vsyscall ()
#1  0xb627bb80 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb627b9b7 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7169000 in ?? () from /usr/lib/kde4/lib/libkdeui.so.5
#4  0x00000001 in ?? ()
#5  0x00000002 in ?? ()
#6  0x08117268 in ?? ()
#7  0xbf9a91fe in ?? ()
#8  0xbf9a91fe in ?? ()
#9  0xbf9ab268 in ?? ()
#10 0x00000003 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
#0  0xb7ef0410 in __kernel_vsyscall ()


These backtraces don't make much sense, both the networking threads are in a system call. And the main thread is sleeping, so where the hell does this assert in QList then happen ?

Beats me. But it's happened to me quite a few times now when selecting multiple torrents to remove.

Unfortunately, I had to switch trackers, so I don't still have ktorrent in a mode where I can reproduce the bug at will. Since I don't exactly understand when this happens and when it doesn't, I'm not sure how easily I'd be able to confirm a fix.

If you want, I can let you know next time I encounter it so testing will be easier?