Hi all,
Its a brand new day & deluge gets a brand new plugin called 'Torrent Pieces' authored by Micah Busy & uploaded by markybob. Thanx guys. Although the plugin is buggy as hell http://dev.deluge-torrent.org/changeset/1204 and it takes 100% of the CPU & kinda hangs for a while before showing stuff but I'm confident these are teething issues which would be solved in the days/weeks to come. Actually markybob did say it somewhere I think about the plugin but don't remember it where. Anyway, nice to finally have some kind of torrent peices plugin although its far off from how we are used to see. I'll put up a screenshot tomorrow ( as its 1 a.m. IST) anyway, good going guys
I'm not sure what's causing this particular issue. I have not been able to reproduce, which makes it difficult to debug. However, current svn, the plugin has been modified, breaking the code down into smaller methods, which should allow better traceback info should this arise again. As for the cpu usage, I have made a patch to slightly improve things (as of now it has not yet made svn).
The bulk of the cpu usage issues comes from the initial display, which I believe is entirely gtk's fault and there really isn't anything I can do about it. Once this patch is applied, you can notice that it is a display issue if you switch which torrent is selected while on a tab other than the pieces (this will automatically update the pieces tab information without having to displayed it yet). In this case it runs rather smoothly, however switching to the pieces tab now, even though all the updated information is in place, it must be displayed for the first time, and this is where the cpu usage spikes.
thanx for clarifying things up, would do some more tests once the compilation is done. From your clarification/answer it seems the spike should only be initial display. Let's take a scenario & let me see if I get it right or not :-
Lets say there are 2 torrents A & B & both torrents are downloading (a real-life scenario & also makes for interesting read)
Now when i switch to A there will be a spike as this is the first time
When I switch to B again there will be a spike as this is the first time
If after some time I again switch to A, there have been updates , it will again spike?
This is what has been happening atleast till now, lemme see if it happens again with the new code, will give more feedback as I know more.
when switching from one torrent to another, the current display is destroyed (also when multiple torrents are selected) and created for the new selection (creation occurs when only one torrent is selected). so cpu will spike when switching from A to B. And then again when switching back to A. cpu will not spike so much if it's not on the pieces tab, eg on the Details tab switching from A to B will just update information for pieces tab, but since it has not initialized display, cpu usage is much lower. The new patch which has not yet been applied to svn will make it so the ui doesn't freeze when just the information is being updated. Hope that helps clarify.
Edit: pieces information also updates when file priority is changed to or from Don't Download
lots of changes to torrent pieces in svn. Gone are the tooltips and progress bars, they just caused too much cpu usage. Now instead a percentage per piece of the blocks finished. also peer speed is represented by symbols per piece.
fast is +
medium is =
slow is -
Completed torrents do not show anything in the pieces tab except a message saying that the torrent is complete.
Font size and number of columns (number of pieces shown in a row) are configurable in the plugin preferences. I don't know about others, but I do not like having to scroll horizontally, hence these options.
Limitation is that in order to line up the columns, a font with same width per character, so right now limited to monospace font.
why dont you make it like other bittorent clients have, and just have a long bar thats basically divdied by how many pieces are are in the torrent, and it slowly fills in as the pieces get downloaded? Seems to be a little easier to read then the current plugin
Polygon wrote:why dont you make it like other bittorent clients have, and just have a long bar thats basically divdied by how many pieces are are in the torrent, and it slowly fills in as the pieces get downloaded? Seems to be a little easier to read then the current plugin
we're more than willing to accept a patch which does this. unfortunately, as time would have it, there are more pressing features which the developers need to take care of before we can focus on something like this. hope you understand
If anyone wants to play with this, I'm attaching a GTK+ widget that should help get you started. I just thought it would be a good way to learn Vala. You can use it as is, or it should be quite easy to port to python.