[Wishlist] Friendly hash check/allocation

Bug #602892 reported by Shiki on 2010-07-07
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
qBittorrent
New
Undecided
Unassigned

Bug Description

Just got an answer at Google Code.

http://code.google.com/p/libtorrent/issues/detail?id=95

Let me post what is written there, if something would happen to that ticket:
Basically I'd like to have a "friendly / smart" hash check. (In qBittorrent, but since libtorrent-rasterbar is the lib its using and the two project works like it'd be one, hope I'm not committing a crime here..)

The feature would be like.. in Vuze for example.

How could one accomplish the "friendly" way? Hmm.. There should be three ways of this.

1) Limitting it. Let's say 5MB/s by default and you can change it (which would be awesome since I didn't find anything like this so far.)
2) Hardcode it. Not the best way, but some client does this.
3) Use some "dynamical" setting. I don't know if its possible and how.
Like determining the maximum disk performance and trying to use the ~80% of it or something like that. If it goes up, the hash check speed goes down (by this, keeping the system responsible.)

Why I think it'd be a good idea?
1) You could do a friendly hash check when any torrent comes down. Doesn't matter if it's big or small, if it's friendly, you don't really care. It takes more time though.
2) On Linux, BSD your DE goes unresponsible during heavy load. On Windows I'm fine, I can still use anything, the scheduler is doing a really good job. On BSD/Linux your DE almost locks up totally. (In the worst case you can even get a segfault .. like I had in KDE)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers