![]() Registered Member ![]()
|
Every time I change the active torrent to one which has 5070 files in 71 directories, it takes a while for KTorrent to become responsive again.
Please make the infowidget plugin to background the file tree creation or only update the active tab the same moment the torrent changes. Thanks.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Moderator ![]()
|
|
![]() Registered Member ![]()
|
3 hours coding + 2 hours bugfixing resulted in the following:
The lock is used because otherwise Qt had some crashes because the listview items were changing while it tried to repaint the widget. Also, it were trivial to modify this to only use a thread when a torrent consists of more than N files. Edit: changed name of QMutex Fileview.lock to Fileview.eventlock.
Last edited by J on Sun Oct 21, 2007 11:56 am, edited 1 time in total.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Moderator ![]()
|
Hopefully this doesn't crash, QObject subclasses are not thread safe. So this looks like a very dangerous patch.
Maybe Qt's event handling for FileView needs to be protected to by the mutex. Suppose you are adding child items to one item, and at the same time the user expands it. Qt's container classes are not thread safe. Can you send that in a file to joris AT guisson DOT gmail DOT com ? Patches copy pasted from the forum have a tendency to not apply properly. |
![]() Registered Member ![]()
|
Perhaps. I've done the following: keep the "files" tab open and scroll through the torrents by holding down an arrow key, and hopefully eliminated at least one bug I encountered while doing so.
The KListView widget is disabled while adding items to the list, so the user can't expand parent items. Also there is a mutex preventing it from redrawing the widget while adding items. And if I get it right, the changeTC function nor the destructor of the Fileview class can be called in parallel, so that one doesn't need a mutex.
It should arrive any time now.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Registered Member ![]()
|
First of all, thanks for the patch, I was going to look at this issue just to find that it has been solved in SVN.
One nitpick though. Would it be possible to avoid the generating of the list completely when it is not visible? I.e. setting just some "tc update pending" flag in changeTC, and starting the thread in update() when there is a pending tc change and isVisible() == true? IMO people usually have the torrent details displayed, not the file list, so this would totally eliminate the useless cpu load. |
![]() Registered Member ![]()
|
I just tried to play with the code a little bit more... the version below generates the list only when it is visible, and does not need a separate thread - it uses a timer instead. I didn't test it very thoroughly yet though.
Applies to r681804.
|
![]() Moderator ![]()
|
|
![]() Registered Member ![]()
|
Whatever you did with this in SVN (738109 I think) - it doesn't work right: the GUI remains unresponsive to interaction and paint events (only the fileview repaints itself) until it finishes loading those files.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Registered Member ![]()
|
Neither previous version (in 2.2.3), nor this one (2.2.4) eliminated blockage of gui for me (I must admit situation got improved a bit though) when selecting a 7000+ file torrent. |
![]() Registered Member ![]()
|
Was my patch included in any of those? The threaded solution I presented earlier worked perfectly for me, but the current situation is almost just as disturbing as it used to be. And as far as I can tell, currently it does generate the list even it is not visible.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Registered Member ![]()
|
It was in 2.2.3. It has been removed in 2.2.4.
The threaded version crashed on SMP systems (includng mine), Maybe you could try decreasing the number of items added in one go, see #define ITEMS_PER_TICK 100. It is possible that 100 is too much for slower machines.
Unfortunately, yes, since the patch I posted has been modified by Joris. |
![]() Registered Member ![]()
|
Any idea or debug info on why it crashed?
I don't think an AMD Athlon 64 3200+ (2,2Ghz) is too slow for this. Personally I still think that using the event loop to do this isn't a good idea as everything else on the event queue will have to wait. This might result in loss of performance in other parts of KTorrent.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
![]() Registered Member ![]()
|
See http://ktorrent.org/forum/viewtopic.php?t=2064 and other threads when 2.2.3 was released. |
![]() Registered Member ![]()
|
Hmm... lol, that did cause a lot of havoc, sry...
I wonder why it did that though... It ran rock-stable on my uniprocessor unicore machine for at least a week. PS: When debugging multi-threaded programs with GDB, use "thread apply all bt" to get a backtrace on all threads.
Thank you KTorrent developers!
![]() _________________ "Thou shalt not steal." - STOP PIRACY NOW! |
Registered users: Bing [Bot], claydoh, Google [Bot], rblackwell, Yahoo [Bot]