Crise

Note: this is the last post on here, copied directly from the new thing. Figured I'd use this to let those people know that still care. You may have noticed some intermittent downtime on apexdc.net over the last couple of days. This was due to rebuilding and upgrading the server. However, as a byproduct of this these forums became a major pain point. This has mostly to do with the decline in activity coupled with it no longer being worthwhile to keep paying for the privilege of having a secure installation because of this. So, to address this issue we now have a slim replacement on a more modern and free platform. Where's the old content? The old forums will remain on the server as read only for archival purposes for the time being. How long it will stick around remains to be seen as it was already necessary to manually patch certain bits to keep it working even in its current diminished capacity. This isn't something that can be done long term on a proprietary and complex code base that I already know more about than I'd care to admit. Selection of topics from the old forums has also been manually imported over and brought up to date so that they may be more easily found and as to not have an unknown expiration date on them (mostly topics that are referenced directly by the main website in some fashion). What about content being organized? By default the new platform will display a view of all recent discussions, but the more traditional categories still exist, one can be picked when starting a new discussion. For a more traditional way of viewing the content you can also go over to the categories tab. Going Forward This is mostly here so that if people want or need to reach people they still can and that there still is a place for people to bring up issues or requests if they feel so inclined. As far as future plans for the project are concerned, currently there really aren't any beyond keeping the client somewhat current and potentially fixing a few bugs along the way where possible.

I am not sure I follow... do you mean the ADLSearch window shows wrong value in a column? If so I can look into it but this seems like a really old bug

The first one is definitely a bug and I will look into it... as for the second one I am certain the tray icon behavior has not changed, but I can still check it out at some point (I seem to recall that in the olden days a tray icon was a requirement for "balloon" popups on older versions of Windows, which is why I am pretty sure it couldn't have changed).

I wonder if anyone expected to see this, ApexDC++ 1.6.5, that is? Notably this version focuses on keeping the client in its current state, well current by updating various dependencies including OpenSSL, the compiler used has also been updated to the latest version. Otherwise some time has been taken to incorporate some changes from DC++, including a high priority fix and a change long overdue to default settings. Update: an obsolete build was accidentally uploaded to SourceForge very briefly, in case you experience any issues with your installation then downloading the 1.6.5 version again should fix it. To find out if you are on the correct release version you may check Help > About > Git commit, it should be the following: 47d5052582fd424d3a54edc33307607d1e87eb2b (if it is listed as something else you are running the outdated 1.6.5 binary) A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.5 as soon as possible. Download: ApexDC++ 1.6.5 Happy Holidays and have a good New Year

I am pretty sure there is no DC client out there (with a graphical user interface) that can handle high volume of hubs very well, of course it depends on hub activity and size as well as any ongoing transfers etc., but the UI's at the very least are not generally built to handle high loads. The only advice, short of looking at a command line client, I can give is make sure all logging is disabled, although this will only primarily reduce disk I/O.

Just as an general comment... running ApexDC, or any DC client, with 80 hubs open is not really a typical use case. Or rather it wasn't one when these applications where created. So they really can't deal with volume efficiently, regardless of whether PM's are spam or legitimate messages. The UI is (or rather was originally) designed in such a way that the user is expected to only open a number of hub connections they can manage manually, which is why there is no real degree of automation in many places when it comes to managing any aspect of the UI. To put it in another way, DC really is not a general purpose file sharing application, as it was never designed to reach a large volume of content at once. Rather it was designed to reach a type of content aggregated by getting like-minded users together, you could say quality over quantity I guess (hence why it has chat featured at least equally if not more prominently than file sharing capabilities). As a bit of a history lesson, the original incarnation of DC was intended as an IRC replacement with a more user friendly interface for sharing files, as using IRC for sending files or using file servers is a bit of a mystic art in itself (and certainly mostly a lost one at that these days). Apart from that the original DC client, out of which DC++ and its many variants were initially reverse engineered from, could only connect to one (1) hub at a time. For more on the history of this thing, look here. Not that it is really good for anything but an interesting retrospective in today's context as the DC of today is completely different from that, but some parts of it still show today, in particular in the way the applications remain structured to this day.

There is no difference, except that the slim package only contains the required binary (ie. the .exe file). Mainly I suggested it so that we can see if the issue is specific to the version bundled in the installer. Having said that the binaries in each case should be identical.

Problems connecting to the update check should not be related to connecting to hubs at all, unless ApexDC is being blocked by either a router or a firewall, in which case it can not access the network at all. What is the connection error message you get in the hub windows (ie. after the line "*** Connecting <address>..."

I have actually recently though about this type of feature. However, pattern and IP matching will only result in a never ending game of cat and mouse. As such the only reasonable compromise I can think of (which can not be circumvented by script and bot authors) is to provide an option to ignore all PM's from particular type of hubs that are not from privileged users (ie. operators) or potentially users you have chosen to exclude by adding them as a favorite user. The problem with above though, is that it is quite a binary choice and can not be configured very well (at the same time, I am not interested in adding a feature that matches Nicks and IP's because of things already mentioned here). At the end of the day preventing bots from getting into a hub in the first place is obviously a hubs responsibility and whatever a client can do is only ever a band aid.

Where did you download the version of ApexDC in question, if you are using the installer make sure it is one from this web site. Also try with the binary only slim package instead.

I probably shouldn't say anything here to be honest, but I am going to anyways. Who won, is irrelevant... the whole concept of winning in this context is somewhat absurd it is not a war or a competition with a beginning and an end after all. I find it amusing that the word enemy even came up here at all. Whether I personally agree with or condone some actions of groups or individuals in the past, one way or another, is a different matter entirely, but also irrelevant. However, actions should have consequences and it should work both ways. I never was keyed into all of the drama, nor did I particularly want to be, however, I believe there is rarely if ever a good reason to hack (or whatever that word actually exactly means/meant here) something or someone. Unless, you have been explicitly asked or commissioned to do so to test for vulnerabilities for example. There is seldom a need to act on something, say a vulnerability, just to make it known. The situations where throwing your weight around is your only course of action should be few and far between (and if it is done, it should be with the knowledge that doing so will likely in turn invite some kind of response from others involved). This applies to all sides not just one or the other. When it comes to DC related projects, each project is free to manage themselves how they see fit, if that management causes ire with others then handling those situations is each projects individual responsibility as is handling any consequences of any decisions made. However, this also means that everyone involved should be able to respect these projects' right to make these decisions and at the very least agree to disagree on amicable terms. Just because you can do something doesn't mean you necessarily should, sometimes that means pushing aside your personal feelings so that you can look at a situation objectively and make the necessary decisions. Either way looking for trouble or making choices that you know are going to perpetuate a cycle can hardly be called productive use of time and resources. To address the matter of hublists, the whole concept while necessary at this time is, from infrastructure point of view, the weakest point in the DC network a linchpin if you will and obviously not in the positive sense. DC has a network structure that doesn't strictly require a centralized entity (above hubs) that has a lot of control in the first place so in the long run there should be an alternative for hublists that can ideally work autonomously. This is the direction that DC should have headed in the first place and it is purely based on the simple fact that a system that is self-managing is legally the most sound option (If you have little to no control over a system you can not be held responsible for exercising control, over said system, which you do not have).

I don't speak german (I think that is german anyway), but those kind of errors are propagated from the file system... my guess is that says the syntax for the file name or path is incorrect or invalid. Which means it is not that the file can not be found but that ApexDC can not save the file on your system. There can be number of reasons for this, however, it should not stop other files from being downloaded. Unless, said errors are so common that they take up all the spaces for active downloads (see Settings > Downloads, under the limits section). If the errors are so common that it is making it difficult for you to use ApexDC, I would suggest looking at the files that this error keeps happening with and seeing what they have in common (such as if they are all from the same hub or same users, or if their names seem strange in some way). Off the top of my head I would also recommend checking that your incoming downloads directory is set in a location that is always reachable. With very long path names the archaic limitations on Windows file path length might also be what is causing this... if you need to have your files in such folders or if you routinely work with files that have long names I would recommend reading up on the matter because ApexDC will not be the only software with issues on those kind of paths (the linked StackOverflow question has some proposed solutions).

Please clarify what you mean by file cannot be found? As far as I know, if the error encountered is "File not available" it will proceed to download files just fine (same should be the case if file has no sources). If there is an issue with these two transfer states it might be due to other features setting the priority of the file or preventig removal of invalid sources. However, initially I am thinking that what you mean with file not being found is not what I am talking about above but rather something else, because I don't ever recall hearing of this issue before (and as far as download queue management is concerned, that hasn't been touched in years).

The upgrade notice says it fixes connectivity issues with older versions (of apexdc) ie. the problem with 1.6.3 discussed here. Hubs should discourage the use of 1.6.3. However, if they are doing the same for .4 then they are in the wrong in the sense that 1.6.4 exist to address the problem with 1.6.3. As far as we are aware, there is no connectivity issues with 1.6.4, with any version of ApexDC or any client that we are aware of. You should be able to use version 1.6.4 or 1.6.2 without problems. However, you should not use 1.6.3. That is exactly what it means, as it says in the 1.6.4 announcement.

We are pleased to announce the immediate availability of another maintenance update 1.6.4. This version fixes connectivity issues with compressed transfers caused by recent updates to the zlib library that we use. These connectivity issues randomly affect both downloads and uploads with clients that are running an affected version of zlib without the appropriate fix included. Additionally OpenSSL and zlib dependencies have also been updated once again, in order to keep things current. For the people who still need the XP compatible binaries, we would like to take this chance to once more remind you about recent changes in release packaging for your operating system. A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.4 as soon as possible. Download: ApexDC++ 1.6.4