Probably been suggested before, but this is important.

[MasamuneXGP]

I've been using DC++ for about half a year now, and I can honestly say that's it's the best P2P out there. I've downloaded tons and tons from this prog, and my only regret my crappy upload rate. There is one thing, however, that the other popular P2P's have on you. This feature absolutely MUST be implemented at some point or another. If you put this in, DC++ will be the absolute king of P2Ps.
MULTI SOURCE DOWNLOADS.

Before I used DC++, i used WinMX. MX was great because you could find a ton of people with small queues and smaller upload rates, queue them all up at the same time and have them all contribute the same file. In DC++, when I search for a file I want, sometimes I get 10, 20, maybe even 30 people with open slots, but with upload rates in the single digits. If you could download from all of them at the same time, you'd get the file a TON faster.

From a programming point of view, I really don't see how this would be very hard. Simply divide the file into pieces of, say, 16kb. Have each source download to a different piece, when one of them finishes their piece, have it start on the next unstarted one. Unless there's something I'm not aware of... like maybe resuming takes time? If that's the case, just use bigger pieces. I cannot see any reason why this cannot be implemented.

From a display point of view, I like MX's style. TreeView it; have the parent be a master progress bar with each source as a child with the individual speeds and such.

With this implemented, files could be downloaded sooooooo much faster, and DC++ would easily be the best P2P ever. Now, I understand this isn't a 2 line fix like some of the other suggestions, and I realize that this would take time, but I ask that you give it priority. Quite simply, this. would. be. huge.

Also, here are a few other simpler suggestions that could be implemented quickly, and would make it a lot more convenient.

1. CRC Checking
This would usuful now, but almost essiential for multisource. When you finish downloading a file, have an option to automatically check the CRC with the source's CRC to confirm that you got the file without any errors. For multisource, you could make it so that you can't add another source unless the CRC of the new source matched the CRC of all the other sources. CRC generation for larger files might be a problem, but can be done with lowered cpu intensity.

2. Remove Files from Queue from Transfer Window
In the rightclick popup menu on the lower transfers window, I'd like to see a command to completely remove the rightclicked file, not just the individual user, from the queue. e.g., sometimes I start downloading a file not because I want it, but because I want to see how fast the guy is. If I see that he's too slow, I'd just rightclick him and click Remove User From Queue. That would stop the download, but the incomplete file would still be there cluttering up my Incomplete folder. And psh, I'm to lazy to find the file in the Download Queue window. So yeah, menu command to completely remove the file would be great.

3. Ability to Grant Slots from a PM window
Much easier than searching through the nicklist.

...and that's pretty much it. I hope you will consider implementing these suggestions.

[Sedulus]

3. Ability to Grant Slots from a PM window
Much easier than searching through the nicklist.

type
/grant
in the PM window

[MasamuneXGP]

=O Cool!! Okay then, forget that one ^^

[TheParanoidOne]

Multi Source Downloading:
Already in the Feature Request Tracker:
[ 649808 ] download from multiple sources at the same time
Plus discussed in threads like this one and this one and many others. I suggest you search for them and see the pros and cons of the feature. Who knows, you may even be convinced that it's not necessarily "a good thing".
Please, no more new threads on it!

CRC Checking
Hashing would be better than this, and a pre-requisite for multi source downloading.
Already in the SourceForge tracker:
[ 662717 ] Hashing
Plus discussed here:
About hashing and a few others.

Delete file from transfer window.
I guess this would be useful in the scenario you described. I know that hunting through the download queue may be a problem, especially if you have a large queue, but do you realise that you get get a flat file view of the download queue? That makes sorting and finding much easier.

How do you see it appearing on screen? What would the behaviour be? If it is another menu item called "delete" for example, I could just imagine people complaining that they deleted the item by accident when all they wanted to do was close connection/removeuser/whatever.

[sdunn]

MULTISOURCE DOWNLOADING == DC:PRO

Now you want to tell me why it CAN NOT BE DONE IN DC++!!??

[TheParanoidOne]

MULTISOURCE DOWNLOADING == DC:PRO

Now you want to tell me why it CAN NOT BE DONE IN DC++!!??

segment downloading is DONE in dc pro

[next]

But DCPro is banned in many hubs. You'll also get your IP banned too. Many hubs dont like multi-source clients.

[GargoyleMT]

But DCPro is banned in many hubs. You'll also get your IP banned too. Many hubs dont like multi-source clients.

Well, as long as they're banning for a good reason. Discriminating against non-DC++ clients isn't too good for innovation and diversity.

[HaArD]

I'm a big fan of DC:Pro it's a truly original DC client trying to introduce some new ideas and features.

However, the multi-segmented downloading feature is not complete, it works, but it's nowhere near as stable as DC++. It is also "dumb", in that, any file with the same name and size can be considered a source, and occasional corruption is not only possible, it should be expected.

The DC++ (and Mods) developers have taken a far more cautious/prudent (also slower) approach and focused their attention on Hashes first. Their eventual solution will almost certainly work better then what is implemented in DC:Pro today.

As for hubs that ban client's because they are capable of multi-segmented downloading.... *sigh* These are the same kind of hub-admins that used to ban DC++ because it could connect to multiple hubs..... They'll get the respect they've earned/deserve.

[GargoyleMT]

Wise words, HaArd!

There's a behind-the-scenes mailing list for most of the DC programmers, I invited Richard and most of the alternative DC client programmers (that I could find addresses for), I hope they all participate.

The next IDC will also have multi-source downloads, but in much the same way that DC:Pro seems to. I hope they both end up supporting $GetZBlock at least, and eventually the hash scheme in BCDC.