poy

perfect! i missed that cozy Christmas feeling! :D

Hey, It's not snowing on the forum. :(

yes but not explicitly; as long as hubs allow standard traffic, they don't need to support anything particular. so NAT-T should work with most current hubs. yes. as far as i have tried, it has always worked for me. there is a survey on <http://dcpp.wordpress.com/2010/06/14/nat-traversal-compatibility-survey/> to gather feedback and try to establish statistics. DC++ only supports NAT traversal on ADC hubs, but i believe StrongDC++ (and ApexDC++) support it on NMDC hubs too. ;)

yes. there's a limit in Win of about 260 chars per path and after that many programs can go haywire, DC++ included. see <https://bugs.launchpad.net/dcplusplus/+bug/238482>.

i think, if you append "/silent" to the command-line used to open ApexDC++ (so in the shortcut properties), it won't ask. the happiest people would probably actually be the guys over at MS, since this would mean they would have managed to maintain compatibility with an app as complex as ApexDC++. oh and i find it ironic that someone nicknamed "pingu" evocates Windows 7... :)

yes this is easier to implement and looks less "home-grown" than using TTH. very well written proposal! you might want to rephrase some of the "we do this and that"s into "x should do this and that"s, so it sounds less personal and more like a real draft. ;)

i have no idea if Excel respects nix line endings or not... can you upload the file somewhere? (like <www.sendspace.com>)

you might have screwed up with line endings; what editor are you using?

https://bugs.launchpad.net/dcplusplus/+bug/237682 http://bazaar.launchpad.net/~dcplusplus-te...k/revision/1263 http://bazaar.launchpad.net/~dcplusplus-te...k/revision/1264

ok. yes, sure it would be better if the login/password could be hidden. but i still can't understand what you're asking for in the vote, could you try to elaborate the question?

"crypted"? i know "get", "post", "put", but "crypted"...? unless you meant "post" through a secure connection? as for the vote, i don't understand it (and can't find the meaning of the "else" either...).

because some countries limit speed to 130 km/h. :)

that's a good solution. the number of detected corruptions would have to be defined, though; 50 is a bit too much... codewise, i think this would need a counter in the FileChunksInfo class if i'm not mistaken. however, this is a workaround and i still prefer the client doing nothing automatically and letting the user cancel the download if he thinks he has to.

this is what i meant with "one's suggestion". i'm against this solution since i think the current technique (go back to the beginning of the block and re-download it) is very useful for corruption handling in most cases. now, in your (very rare) case, i believe you pausing/removing said download by yourself would be better than an automatic thing that would cancel every downloads which could have been easily corrected by the current technique.

this seems to be what causes the segment to be downloaded ad infinitum on Excelsium's computer. one's suggestion would be to act the same way the client acts in the case of a "TTH inconsistency" (remove the user from the queue), but i'd be against this solution: i find the current corruption handling pretty nifty. that's why i agree with Big Muscle: the user should fix this on his own; the problem is on his computer. and if he can't fix it, he can cancel the download himself...