Crise

What Mek stated is one of the reasons yes but there are others as well...

That is troublesome... I'll see if I can reproduce the issue (though unfortunately no success thus far). So that I can look into it more.

Aha, so it is as I though, that is intentional behavior...

I really don't get what is wrong with number 1. as for number 3. that was an intentional change... thinking of changing it back soon.

Try removing the plugins, though if you just use them with default settings I see no reason for such extreme change in CPU usage...

Are you using any plugins with 1.2 series?

Are you using any plugins with 1.2 series?

I don't know, because I have yet to experience the mentioned issue...

It's not a bad idea, but recording all those stats can be a pain...

Could be because you forgot to allow the application again when exe changed (since ESS should ask you again when application modification has been detected). I use ApexDC++ 1.2 with ESET ESS perfectly fine without any issues.

Well I am very happy the solution was found, since hardware specific issues is not something that I can easily deal with :D

See advanced -> experts only there is an easy solution. :angry:

That option is there... just as before. There is no issue Get file list and Browse file list just behave differently . (Get file list downloads the whole list while browse does not). This can hardly be correct as we don't even release a version every month. Also when we do "discontinue" products it is never just because we can. Again, this is not the case... when developer brings up licensing, obligations, etc. that simply means that the developer is frustrated and annoyed. Besides more than enough reasons have been given in earlier posts.

First, GeekGyan, I am I correct in assuming you are speaking about filelists downloaded from search window. Because with all other filelist requests (ie. from hub user list f.ex.) the whole filelist certainly is downloaded. Now, Hawkwing, I never thought I'd be saying this either... but I will. You see, we have no obligations of any kind towards users that choose to use ApexDC++. We aren't even required to guarantee that our software is fit for usage for some particular purpose. In other words we aren't required to provide any kind of warranty or even listen to our users for that matter if we don't want to. To put it in other, less fancy, words: what we choose to do with ApexDC++ is entirely up to us as long as we comply with the terms of GNU GPL. In this case we have made a choice regarding upgrades to the most recent version of ApexDC++. Whether it happens now or after one bug fix version is also a choice we have to make. When making these choices it's also by our choice whether we decide to inform the users about our plans in advance or not. Much in the same way that it is your choice to either use ApexDC++ or not to use it. The reasons why we have made our choices have been given earlier in this topic and we see them as perfectly reasonable but if you don't you always have the freedom of making the choice to use another client as I already stated above.

Regarding the matter with TLS, it doesn't make setting up any more difficult, you just forward 3 ports instead of 2 or 2 ports instead of 1 (in case you have used same port for TCP and UDP until now). Regarding the reported issues... there will always be issues, of course we will reconsider the decision to enforce upgrade in the light of the reported issues. That much should be obvious to anyone who realized that Lee's post was made right after release.

hmm, what's interesting is that I tried to reproduce this few times now and thus far everything seems fine. Does this happen for you every time you add files to share?

It still needs to be configured... regardless of protocol, since SDC implemented TLS for NMDC client<->client connections as well.

It's simply a matter of finding the common factor... with the hubs causing this.

With 1.2.0 beta or newer TLS port must be correctly forwarded and configured (it also cannot be the same port number used for the two other port fields).

I tried both of those hubs still running stable here... (with default settings for the script). But I can still venture a guess, since by the looks of it at least one of those hubs uses "weird" characters for it's messages (ie. cyrillic or other). My guess is that this is the source for the issue since majority of hubs still seem to work without any issues. I'll dig deeper into this, however, in the worst case scenario it might not be possible to fix this inside the plugin but a new version of Apex might be necessary (in which case the fix itself won't be released so soon, since at least a few fixes are needed to warrant an update for ApexDC++ itself).

Try disabling fast hashing and see if that makes any difference...

with what settings (for the script) did you get the crash on that hub... since with defaults it seems to work just fine

well I can't even run your script (1.1) properly (your ownChatOut seems to block all messages for me). Edit: this same issue with ownChatOut is also valid for 1.3 version of the lua plugin and 1.2.0 beta.

Yep if you load the plugin at runtime (ie. when using load or reload) restart is required. Regarding changing the toolbar positions it is possible to do that with 1.2.0 as well. However, due to the media toolbar being created after the toolbar positions are loaded and applied from settings it does not respect those settings. Toolbar created from a plugin has certain limitations because there are many aspects that you have to worry about which you do not normally have to care.

Are you guys perhaps referring to the missing spam button on the toolbar? If so that was left out intentionally.