Big Muscle

any reason for pressing that button so many times ?

yes, disable segmented downloading

but it should be else it's bad application :)

it happened to me too, but it's hard to fix it when it's not easily reproducable

"MS Shell Dlg" is not the font. It's only substituted name for font which is set for dialogs :P

this change has no meaning because only apexdc would know it

for ADC it selects correct hub, but for NMDC it's that one which is connected first. A and B are the same-nick user but one from hub A and the second one from hub B: Situation #1 * you connect to A * A is connected and decided hub is correct A * you connect to B * B is connected and decided hub is correct B Situation #2 * you connect to A * you connect to B * B is connected but decided hub is incorrect A * A is connected but it will be disconnected due to unknown connection

you can lose slot only in hubs where the emulation is enabled. So, you are in 2 hubs A and B => A with emulation, B without emulation. You have file with 2 sources - one is in hub A, the second one is in hub B. So you can lose slot only for first source which comes from hub A where the emulation is enabled.

the best solution is not to use DC++ emulation ;)

I think that Apex has longer pause beucase it sends partial info to all partial source before starting new chunk... but it's only my guess, so I can be wrong ;)

try to fix this error by type casting NULL to (Pointer<FileChunksInfo>)NULL or something like that.

aah.. now I understand the whole problem. It's what Crise said. If you have DC++ emulation enabled, then one segment needs to be disconnected when it gets to the part which is already downloaded and therefore you can lose the lost. It's because DC++ doesn't use chunked transfer so you can't request file by chunks but you must request it by whole file size. And current protocol has no command to cancel to transfer, so it must be completely disconnected. There's no such problem when DC++ emulation is not used (then it behaves how I described above) And this has been discussed many many times.

There can be a pause. But realize what happens during this pause - client sends and receives one $ADCGET/SND command and it has about 140 bytes together. So if there's 1 second-long pause, it means that your connection speed is 140 bytes/second. And take in account there's some pause. You can't lose your slot even in the case that this pause is 2 minutes, because your connection is not disconnected. You can lose slot only if you disconnect it or the remote user disconnects you. I don't think that "matt" is idiot. He just says nearly what he sees. But it's like "hmm, progressbar stops and starts from the beginning, so there's one second pause (especially when the progressbar is updated maximally once per a second to decrease CPU usage) and I think that I can lose my slot" and this is only his thought, so he starts to spreads the guff over the network, so everyone will think the same :-/

wow, you have talked to OPs that you are a leecher and you don't want to upload? :P

so a) substract two following items :stuart: count min(1 MB, filesize / 100) :whistling:

They just don't understand how it works. Yeah, there's the pause, but neither 1 nor 2 seconds, it's only a few miliseconds. I'm just guessing that this user has never counted how long the pause is and only says "it's 1-2 seconds" also the phrase "you can easily lose that slot" is false. You can lose your slot only when you are not connected, but during this pause you are not disconnected and your slot is still held. I'm just guessing that this user has never lost slot in this situation and only says "you can".

ah, now I understand where the bug is it is because filelist size in queue is -1, but CBarShader supports only unsigned size. Thank you for your hint, I'll fix it with a little bit different way :)

Any news about this crash? I wanted to reproduce it but I'm not able to do it, so I can't to fix it but I'd like to fix it very soon.

not displaying search result is blocking too and again WE ARE NOT LEECHERS (only you seem to be a leecher) and there's one small thing - it's impossible not to send search result to some type of clients, because you don't know that type during a search :blushing:

no blocking feature will be implemented, we are not fake client to block any upload. Once again, ask the hubowner to forbid these clients... or change the hubs.

there's TTH getting tool in the File menu, so everyone can compre the TTH. And you loose many things in a second check - from HDD abrasion to "time", which is the biggest reason of removing such unuseful check.

I removed "Check again TTH after download is finished" option because it's completely unuseful. Files can be corrupted only if your hardware is damaged or you corrupted them manually and it's not the role of DC client to check this. Imagine one situation I had in the past: StrongDC++ downloaded the file with correct TTH. Then my friend came to me with external IDE harddrive connected via reduction to USB. But after copying that file to this HDD, the file got corrupted (and TTH was changed). Should your DC client also count with this situation, because corrupted file was originally downloaded with your DC client? I don't think so. DC client should only ensure that it doesn't corrupt files itself or they haven't been corrupted during the way from remote DC client to your DC client :P

No, they don't :-P The change has been made by author of DC++, the most used client. There's no other so wide-spread client and since original NMDC client is dead, there's no reason to maintain the support for it. it's true that it's not up to developers to decide which clients it can connect to, but it's up to developers whether their client will manage files without TTH (which can be corrupted, but you can't verify that).

there's no disconnection puase is defineable by your and user's connection speed and it is how many time the "$ADCGET" command takes

i've tested it, but there's no memory leak. If I make the change which PPA proposed, it does nothing :)