djbarney

Hiya BM, any news on progress in this area m8? I would love to see an option (can be disabled by default ofcourse) that would "prefer" different ip's.. Let me explain my current situation: I am in around 10 to 20 hubs right now, all kind of focussed on electronic music. A lot of other ppl do the same. So when i connect to these hubs, it can happen that i find a user called "insertnicknamehere" in hub 1,2,3 and 7 that i am in as well. That's not a problem, the problem for me starts when this "insertnicknamehere" queues some tracks from my share, because apex currently sees "insertnicknamehere" from 4 different hubs, as 4 different users. As i spend a lot of time on these hubs, and i dont mind filling my uploadspeed to ppl, queues of uploaders of over 100 different users can appear in my list, sometimes even more. Still, i have no problem with that. The "problem" for me is, that sometimes there's 100 different users waiting for a slot from me, and "insertnicknamehere" is taking 4 or 5 slots out of the 15 i have opened. Now that is unfair imo. "insertnicknamehere" could take just 1 slot, and leave those other 4 slots he's using (often for the same file as well, cuz of the segmented downloading features in various clients) for other users that are waiting for a slot. I really dont mind if "insertnicknamehere" takes all of my slots while they are open and available (i'd rather see my uploadstream being used then being unused) but i do mind when "insertnicknamehere" uses multiple slots while other ppl are also waiting for a slot. To me it feels like that user is very greedy then. So what i would like, is an option that would look at the ip-adress of a user that wants to download from me, and let the client check if that same ip-adress is already uploading. Basically a "1-slot per ip-adress" idea. To make that idea more fair even: i'd like to see that it checks available slots before it allows or denies the upload. With that i mean: "if ip is already downloading & if open slots is bigger then 1, allow upload" and "if ip already downloading & open slots is 0, queue upload like it does normally when slots are unavailable" I'm not great with coding etc, but i think that something like this could be made pretty easily and would really be an improvement to the client, because it will open up slots for other users that are otherwise hogged by the "greedy" users. I'm not sure, but i have a feeling that some dodgy clients are forcing connections, or are requesting uploads way more often then normal clients, because i happen to see a lot of the same nicknames hog up multiple slots vs normal users. With this requested function, i guess those ppl would be handled exactly the same way as normal users. Anyways, long story, hope it makes some sense =) /djb

bit late i guess, but i'd love a feature like this too. And i dont think it should be too hard, i get that it's nearly impossible to identify nmdc users from eachother, but couldn't you make it an "option" that's standard turned off, to "block multiple ip's" ? plus, i guess you could easily identify a user by the myinfo stuff he sends. Anyways, hopefully you could still have a look at this if u got some time for it =)

congrats on a new version again! nice job guys, let's see how it performs =)

Hiya guys, first of all: congrats with this milestone release! On to the "bug" i noticed after first starting this final version: the file uploadspeed bug as reported in beta5, is still there. Upload speeds of lower then 4,56kb/sec are shown as 0kb/sec, even though they are transfering.. and it seems to do this with multiples of 4,56kb/s. So apex isnt displaying the actual speeds for the uploads (strangely enough, it seems to do correctly with the download speeds) It's not a big bug imo, no showstopper or whatever, just a minor flaw that i think could be worth reporting =) I do use netlimiter to limit speeds to about 80% of my upload capabilities, but turning netlimiter off or de-installing does not change the values that apex shows for file uploads. Hope u guys can have a look at why this is caused and how to fix it for the next version =) the previous topic about this certain bug is in here btw: http://forums.apexdc.net/index.php?showtopic=2362 /djbarney

Congrats on this huge milestone guys =) will give the final a spin tonite nd see how it performs. On to v2.0 now then eh? :thumbsup: /djbarney

same issue here indeed, netlimiter indicates that the upload speeds are stable and good, but it's just the column in apex that shows the rates wrongly.. /djbarney

hiya guys, except for the upload speed bug, everything has been running smooth for days on end here now, very good, actually noticing less cpu nd ram usage here too now (where the alpha somehow used some more then b4 did here) Hopefully that little bug can be squashed sometime, aint first priority to me though, client seems to run good speeds anyways =) /djbarney

congrats on this release guys =) will switch from alpha to public beta. /djbarney

congratulations team! here's a toast to the next big milestone for apexdc =) :crying: /djbarney

and why is vista the problem? little more info would be nice.. it's too easy to just blame vista for everythin goin wrong.. /djbarney

hmmz been movin around with empty xmls, old xmls nd just clean installs nd it keeps crashing now every time.. cant put the finger on where and why tho.. one time it crashes during chat, other times while minimized, sometimes 5 seconds after i start it, nd sometimes after 5 hours of running.. are the devs working on this atm? haven't rlly heard any news for a while, so just wonderin =) /djbarney

after finishing rehashing, it took about half an hour and the crash got back again.. next step will be to remove all xml settings and queue etc, nd add the files back to a totally clean install one by one to see where it goes wrong.. hope it might give some clues bout where and why it goes wrong.

ah sorry.. didnt check if it was posted before.. was in a hurry when posting it.. tried the /rebuild nd ended up deleting the hashindex.xml & dat, it's re-hashing now, hope it'll work.. if not i'll post back here again /djbarney

actually, i left the client on last night, nd when i woke up nd checked the pc, it had crashed again, exactly same error, just different time. this time it was in minimized mode though, so i dont know what it was doing at the time of the crash.

hiya guys, just recieved a crash with 1.0.0b4 running under vista home premium, with the following exception info: Code: c0000005 (Access violation) Version: 1.0.0B4 (2007-08-07) Major: 6 Minor: 0 Build: 6000 SP: 0 Type: 1 Time: 2007-09-27 00:54:01 TTH: 7CNQCQXDGEV7S2IDTUSYEW73M722LLS7BVOOXDI ntdll!0x77B02E7B: RtlEnterCriticalSection d:\cvs\apexdc++\trunk\client\filechunksinfo.cpp(809): FileChunksInfo::verifyBlock d:\cvs\apexdc++\trunk\client\merklecheckoutputstream.h(119): MerkleCheckOutputStream<MerkleTree<TigerHash=0x0C2D3930,1024>=0x00000403,1>::write d:\cvs\apexdc++\trunk\client\chunkoutputstream.h(79): ChunkOutputStream<1>::write d:\cvs\apexdc++\trunk\client\filteredfile.h(133): FilteredOutputStream<UnZFilter=0x04DEC008,1>::write d:\cvs\apexdc++\trunk\client\downloadmanager.cpp(533): DownloadManager::on d:\cvs\apexdc++\trunk\client\userconnection.cpp(180): UserConnection::on d:\cvs\apexdc++\trunk\client\speaker.h(64): Speaker<BufferedSocketListener>::fire<BufferedSocketListener::X<3>=0x073BFF00,unsigned char *=0x073BFEF8,int> d:\cvs\apexdc++\trunk\client\bufferedsocket.cpp(263): BufferedSocket::threadRead d:\cvs\apexdc++\trunk\client\bufferedsocket.cpp(515): BufferedSocket::checkSocket d:\cvs\apexdc++\trunk\client\bufferedsocket.cpp(531): BufferedSocket::run d:\cvs\apexdc++\trunk\client\thread.h(161): Thread::starter f:\sp\vctools\crt_bld\self_x86\crt\src\threadex.c(348): _callthreadstartex f:\sp\vctools\crt_bld\self_x86\crt\src\threadex.c(326): _threadstartex ntdll!0x77AFA9BD: LdrInitializeThunk hope it's of any use for u guys, the crash seemed to occur when i searched for alternates on a file, and it had just recieved a couple of results in the searchwindow. /djbarney