Gew

Can't find the option under Advanced anymore. Has it moved? Is it removed? Can I do it manually in some "ugly" way besides adding a firewall rule that prevents ApexDC.exe from connecting to whichever update server it uses?

Client is awsome. Just one little "request" that would probably take secs to implement - a hotkey for us keyb freaks to focus the Quicksearch field in the upper panel. CTRL+SHIFT+Q, SHIFT+Q, ALT+Q. Just anything. Ty in adv. Regards~ G.

Please disregard this whole topic. I - finally - found what was causing my itch. Eg, all StrongDC++ family/core clients (AirDC,StrongDC,ApexDC) wouldn't last more than a couple of hours tops (my record was 12h) before unexpected exception error, ofc while being minimized to tray. It deemed to be a memory issue, that was entirely "on my end of the line". Note to be taken for other users though, such seemingly unexpected crashes could(!) ('cuz in my case it was) memory-related. In my case for such, I decided to add a 512MB chip (DDR400) mem, giving a total of 1

Code: c0000005 (Access violation) Version: 1.2.1 (Jul 11 2009) Major: 5 Minor: 1 Build: 2600 SP: 3 Type: 1 Time: 2009-09-11 12:34:00 TTH: 7MLMHEJD3MGC64HENDRW6TQRSPLRKQXBEEAC3DY COMCTL32!0x7741A026: Ordinal384 COMCTL32!0x77421B12: Ordinal384 USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E42A013: IsWindowUnicode USER32!0x7E42A039: CallWindowProcW d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3089): ATL::CWindowImplBaseT<WTL::CListViewCtrlT<ATL::CWindow>=0x01892E4C,ATL::CWinTraits<1442840576=0x00000000,0> >::WindowProc USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E42927B: GetParent USER32!0x7E4292E3: SendMessageW d:\development\apexdc\trunk\windows\typedlistviewctrl.h(213): TypedListViewCtrl<SearchFrame::SearchInfo=0x01892E4C,1019>::findItem d:\development\apexdc\trunk\windows\hubframe.cpp(1956): HubFrame::updateUserList d:\development\apexdc\trunk\windows\hubframe.cpp(553): HubFrame::updateUser d:\development\apexdc\trunk\windows\hubframe.cpp(602): HubFrame::onSpeaker d:\development\apexdc\trunk\windows\hubframe.h(76): HubFrame::ProcessWindowMessage d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3086): ATL::CWindowImplBaseT<WTL::CMDIWindow=0x018928B0,ATL::CWinTraits<1456406528=0x00000000,64> >::WindowProc USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E4189CD: GetWindowLongW USER32!0x7E418A10: DispatchMessageW d:\development\includes\wtl\atlapp.h(1027): WTL::CMessageLoop::Run d:\development\apexdc\trunk\windows\main.cpp(445): Run 0x003900F8: ? ApexDC!0x0044B387: MainFrame::FileListQueue::`scalar deleting destructor' ApexDC!0x00468399: [thunk]:MainFrame::`vector deleting destructor' 0xEC83F8E4: ?

Thanks for your response Big Muscle (and also bigups for the creat client core of yours). I come to realize just about what you just confirmed, but it was a long night's struggle, hrhr. Reading the "unified PFS description" (on various software sites which link to StrongDC++) states: I have to say, this is quite misleading, since it got to me as that [to draw parallels w/ torrent function] my downloaded files would automaticly be "unseeded" after they'd finished. However, when I got those - to me then confusing - uploads started (subject of this thread) I started to think deeply in all sorts of aspects, like that thing with that it could have been some user that I'd disconnected earlier that has got some sort of unique slot for this particular file inplented somewhere in some of the hash data/xmls. I therefor started labbing, ran another client, with no queue/hash (fresh install) and tried connecting to an co-connected hub. Searched for the file, and (like you say) I wasn't listed as a holder. However, I then tried starting the download from another user, and then ran "search alternatives", and now, it suddenly had me uploading again. I pounded my head and kept brooding what could be the case. I then thought to myself that it could perhaps be the thing with "earlier granted/implented slot for specific user", but based on IP, and therefor I would automatically reconnect even tho on "fresh install", since we were on the same IP. Then, to laborate further, I got to a machine with another IP, and tried from there, same thing, I started uploading. After this (final) test, I had sort of come to the conclusion which you're confirming in your post Anyways, thanks for the direct and solid answer. Cheers!

Hiya. I knew that playin' the game w/ segmented downloads enabled will cause me to upload while downloading a file. However. Today, I downloaded a file, and after my download was finished, I reckoned uploading the same file ~2h _after_ I had finished my download. Why is this? Is it normal? I presume it's fully normal. However, I'm quite interested in "what's cracking under the hood". So, how long are downloaded files shared _after_ they've finished downloading? Until I've restarted my DC++ client? A set time? Regards in adv~ G.

I've made a 2nd revision of my post, where I try to be a bit more "on to point" to avoid confusion. Here goes: I downloaded file x.mpeg; segmented, of course. Meanwhiles downloading, I, of course, uploaded to several other users. _This I know_ about segmented downloading. However, what I also thought was that when I had finished my download, the file/segments would no longer be available to new(!) users eg. those who search for the file. Anyways, (hours) after my download had finished, I checked on my tray-minimized client and noticed that I had started uploading the file to a few new(???) users. Is this behaviour normal? And if that is the case, then for how long are my segmented downloads "automatically fully shared"..? A specific time? Or up until I manually close/restart my DC client? Alternatively rename x.mpeg to ie. x.mp3g or something like that. Anyways, I'm really more interested in what's going on "under the hood" here! To be honest, a point to add is to this is that it could be that I had ..erhm.. well.. disconnected some of the user whom I was uploading to (while I still hadn't finished my download). In this case, could it be that these particular users - whom all of a sudden (hours after I finished my dl) is downloading from me - had automatically been granted a "liana" (upload slot for the particular file) since he's requested it __meanwhile I still had not finished my download__ ; thus being able to reconnect/resume it (later on)even though I'd then be finished downloading? This could then be a considerable explanation to this. I've tried a few Google strings for some tutorial that explains how DC's partial file sharing works step-by-step, but I haven't found an satisfying answer yet. I tried executing a 2nd instance of APexDC++ and chose a specific hub to co-connect to, then I searched for "x.mpeg" with new instance of ApexDC++, then %original-instance-of-client% did not come up as result, which was at least semi-comforting; giving some strength to my hypothesis stated above. Thankful for all answers. Regards~

Mystery solved! At first I found comfort in your reply, but after less than an hour I started feeling ill at ease (Nb. I have some personal compulsive issues) with the fact that your answer consisted of the "T word". I wont around in circles and didn't know where to go. Then I found my path to the DC++ Launchpad. I punched my issue over there, and the kind man on the other end of the service line gave me a very desirable answer only approx. an hour later. DC++ question #83285: â

Hi. Yeah, I just wonder how the darn thing prioritize it's searches. I've set the interval to 5 min (lowest) and when I watch the syslog it indeeds searches every fifth minute, but it tends to make some sort of random choice on which one (of the many files in my queue) it will search for. Or, well, at least it's no alphabetic logics in it. Any ideas? I would just be glad to know the deal. Regards~

First of all, ty for your quick response. I suffer ADD and the second I reckoned the auto-search was obviously not going by alphabetic order I felt the urge to know, and FAST; thus flamed a couple of boards etc. Had a few pre-pondered hypotheses. "Totally random" (eg. like you well confirmed), "Based on added-to-queue-timestamp", "Based on alphabetic order, by the TTH sums in queue.xml", and a couple of others, more or less unlikely. However, now I install that statement of yours in my mental knowledge database as De facto in this matter, so that I can rest easy and move on with my life. Oh yeah, the picture, indeed! :)

I believe these two crashes could have something to do with having leftovers slash "ashes" from previous "client attempts" in the unfinnished folder; eg. .dctmp files (supposedly) "blocking" the writing of new ones. After fully emptying those, I had a stable run for quite the whole evening yesterday. However, now when I woke up and checked the tray, it's a mess. One of these crashes where the cpu cycle has actually frozen so that I won't even get to see the actual crash message, the traybar uptime counter is just frozen n all. However, I checked ApX dir and it had written a exceptioninfo. Here's what I got. Code: c0000005 (Access violation) Version: 1.2.1 (Jul 11 2009) Major: 5 Minor: 1 Build: 2600 SP: 3 Type: 1 Time: 2009-09-12 10:41:43 TTH: 7MLMHEJD3MGC64HENDRW6TQRSPLRKQXBEEAC3DY d:\development\includes\stlport\stlport\stl\_hashtable.h(499): d:\development\apexdc\trunk\client\user.cpp(109): dcpp::Identity::get d:\development\apexdc\trunk\client\user.cpp(93): dcpp::Identity::isClientType d:\development\apexdc\trunk\client\user.h(123): dcpp::Identity::isOp d:\development\apexdc\trunk\client\user.cpp(369): dcpp::OnlineUser::compareItems d:\development\apexdc\trunk\windows\typedlistviewctrl.h(279): TypedListViewCtrl<dcpp::OnlineUser=0x015E7638,1006>::getSortPos d:\development\apexdc\trunk\windows\typedlistviewctrl.h(200): TypedListViewCtrl<dcpp::OnlineUser=0x015E7638,1006>::insertItem d:\development\apexdc\trunk\windows\hubframe.cpp(551): HubFrame::updateUser d:\development\apexdc\trunk\windows\hubframe.cpp(602): HubFrame::onSpeaker d:\development\apexdc\trunk\windows\hubframe.h(76): HubFrame::ProcessWindowMessage d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3086): ATL::CWindowImplBaseT<WTL::CMDIWindow=0x011A0CE8,ATL::CWinTraits<1456406528=0x00000000,64> >::WindowProc USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E4189CD: GetWindowLongW USER32!0x7E418A10: DispatchMessageW d:\development\includes\wtl\atlapp.h(1027): WTL::CMessageLoop::Run d:\development\apexdc\trunk\windows\main.cpp(445): Run 0x00230132: ? ApexDC!0x0044B387: MainFrame::FileListQueue::`scalar deleting destructor' ApexDC!0x00468399: [thunk]:MainFrame::`vector deleting destructor' 0xEC83F8E4: ? I would much appreciate if someone could tell me some sort of probably cause. Ty in adv.

And another one... Code: c0000005 (Access violation) Version: 1.2.1 (Jul 11 2009) Major: 5 Minor: 1 Build: 2600 SP: 3 Type: 1 Time: 2009-09-11 15:47:58 TTH: 7MLMHEJD3MGC64HENDRW6TQRSPLRKQXBEEAC3DY COMCTL32!0x7741A026: Ordinal384 COMCTL32!0x77421B12: Ordinal384 USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E42A013: IsWindowUnicode USER32!0x7E42A039: CallWindowProcW d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3089): ATL::CWindowImplBaseT<WTL::CListViewCtrlT<ATL::CWindow>=0x00C3F5A4,ATL::CWinTraits<1442840576=0x00000000,0> >::WindowProc USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E42927B: GetParent USER32!0x7E4292E3: SendMessageW d:\development\apexdc\trunk\windows\typedlistviewctrl.h(213): TypedListViewCtrl<SearchFrame::SearchInfo=0x00C3F5A4,1019>::findItem d:\development\apexdc\trunk\windows\hubframe.cpp(582): HubFrame::removeUser d:\development\apexdc\trunk\windows\hubframe.cpp(635): HubFrame::onSpeaker d:\development\apexdc\trunk\windows\hubframe.h(76): HubFrame::ProcessWindowMessage d:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlwin.h(3086): ATL::CWindowImplBaseT<WTL::CMDIWindow=0x00C3F008,ATL::CWinTraits<1456406528=0x00000000,64> >::WindowProc USER32!0x7E418734: GetDC USER32!0x7E418816: GetDC USER32!0x7E4189CD: GetWindowLongW USER32!0x7E418A10: DispatchMessageW d:\development\includes\wtl\atlapp.h(1027): WTL::CMessageLoop::Run d:\development\apexdc\trunk\windows\main.cpp(445): Run 0x00D1006C: ? ApexDC!0x0044B387: MainFrame::FileListQueue::`scalar deleting destructor' ApexDC!0x00468399: [thunk]:MainFrame::`vector deleting destructor' 0xEC83F8E4: ? I would appreciate if someone w/ some intel slash knowledge could fill me in on what'd be the case here. AFAIK (after some Google research), atlwin.h is about hashing on it's whole. If it matters, I could tell you that my share folder contains the following files, all with verified md5 sums: slackware-12.2-install-d1.iso.asc slackware-12.2-install-d2.iso.asc slackware-12.2-install-d3.iso.asc debian-40r6-i386-DVD-1.iso debian-40r6-i386-DVD-2.iso debian-40r6-i386-DVD-3.iso Fedora10-i686-Live.iso kubuntu-8.10-desktop-i386.iso slackware-12.2-install-d1.iso slackware-12.2-install-d2.iso slackware-12.2-install-d3.iso ubuntu-8.10-desktop-i386.iso slackware-12.2-install-d1.iso.md5 slackware-12.2-install-d2.iso.md5 slackware-12.2-install-d3.iso.md5 I'm running Win32 (XP2600SP3 Eng; Kernel Version 5.1.2600.5755). CPU is an Celeron 325 Prescott (2.53GHz) w/ MMX & SSE1+2+3 instruction capacities. I've got 1x1024MB + 1x512MB (a total of 1

Hiya! I don't use DC to chat, but to retrieve files. I'm sick of all the bot-sent privs I get all the time. Please tell me that there is some sort of "Ignore ALL private messages" checkbox somewhere in the settings menu, I've made a foreseeable search for it but wo/ any luck. This is the main feature I missed in the good ol' DC++ .674, and I assumed that I had some developer out there who felt the same, and had written a tiny scrap of code for it; thus downloaded bcdc/strongdc/apexdc/revconnect. Now, how do I reach sucess in having all all PM's ignored/never showing up..? :whistling: Ty in adv.

Fair enough(?), I found the "Close all PM boxes" click in the Window dropdown-menu. Always something. Anyways, since 'em stupid bots keep flaming my sorry ass about ie. "Search disabled unless you share xx gb's" and suchlike, it's a daaarn lots of Window/Close all PM's clicks. Would be easier if they didn't come up at all. Still nothing? Oh, partly off-topic but I just had my first freeze. It's true what they say about v1.2.1, it crashes. Celeron CPU here.