Crise

Assuming hub has a +report command that would be: BMSG %[mySID] +reports%[userNI]sisssharingsforbiddensfilesscontaining:s%[userCS]n Where the last n represents an actual new line character (0x0a) not escaped new line in the message (which would be represented as the physical characters "n"). All I can really do in terms of ADC is point people to http://adc.sourceforge.net/ADC.html Probably coming too late to be any help for you in particular, but for future reference.

One thing to note, the version linked in this topic is very old, there should be a newer version of it on android market. That said it is a paid app and I do not know if the development for it is still ongoing even. ps: 4.0 isn't half bad .

True, uploading tailored filelist is very much possible, but because of how clients behave when adding files to queue from filelists this method is fundamentally inferior to magnet links. What i mean by this is of course that when file is added through filelist, the user who "owns" said filelist gets added as file source... and when there is a source the client does not search for tth alternates immediately, so everything would operate with a notable delay at the very least.

The more conventional approach to new content would be to have the script in question generate a list of magnet links, then set up a bot that will deliver said collection of links to the user on request (think +newfiles chat command). Writing this mobile, so excuse the lack of references and links.

CDM debug messages not verbose enough for you? Besides in case of connection problems it wouldn't still be able to give you that much, as in connection time out is still connection time out etc.

Works on my version just fine .

Update your client to newer version. Also please don't bring up older (as in over a year old) topics like this one. Create new one instead, next time. Would go into more detail but writing this from a phone so will pass.

Welcome to what is hopefully the first of many blog style articles here at ApexDC.net. This time I hope to give a bit more depth to the new version that is literally just around the corner, especially since it has been a while. Taking one of the new changes under the magnifying glass. This involves a bit of history and hopefully gives an entirely new meaning to one of the pretty meaningless looking lines that from time to time appear in our list of changes despite Lee's best efforts at writing it out so they would not appear. Those who have followed the ApexDC project for a longer time period, might remember that with 1.1.0 we introduced automatic update system in ApexDC. However, if you remember that you must also remember how relatively quickly afterwards we stopped deploying updates in this manner. At that time making the choice to move away from the (then) newly implemented system seemed like clear regression to me, but looking back on it now I know the correct choices were made back then. The reasons for not automatically update our users anymore and revert back to the infinitely more annoying (for you) method of handling updates can be covered by three key points (not in any particular order): Automated updates gave the users one less reason to visit the web page, reducing overall activity on site and in the community. Automatically replacing users binaries has several security considerations that were not really properly handled back then. For example consider the domain being taken over and a malicious individual could feed unknown code to users that then get executed on the users system as a part of the update process. The implementation back then wasn't very flexible and was also somewhat prone to unnecessary failures. All of this is history, from a few years back, but it seems good ideas die hard - this one in particular has come up on multiple occasions since then and, like those of you who have been paying attention to our recent public testing know, we recently decided to revisit the idea of automated updates. Needless to say I wouldn't be writing this if the above concerns were still valid, but why am I do it then exactly. It all comes down to one thing really. Every time we release a new version, we have to lay out the changes in that version and more often than not the list of changes has some entries that bear little to no significance to an actual user, so we decided to elaborate a bit on one such change in the 1.5.0 release. The change involving the update check got chosen especially because it involves not an entirely new feature but most likely a forgotten one. So yes, automated updates will be a prominent sight in the future of ApexDC as we keep thriving for better user experience. Sometimes it may take a while and be long time coming, like in this case, but it will be coming now and in the future. ApexDC is an important project for everyone involved and when we make decisions concerning it a great deal of discussion and thought always goes into them. However, when the decisions get made initially we don't always go into great detail about the reasons behind them, but usually those reasons are in fact good. As we come to a close here, I would like to take a moment to thank all of you who participated in our public beta test and stuck through it with us. Based on the feedback from this time, I think we can safely say that it is more than likely that we will do something like this in the future as well. In the mean time, while we do not know how often we will be making posts like this in the future if you have topics that you'd like us to cover feel free to leave them in the comments below, even if you just want us to voice our opinions about something, I am sure as long as the topic inspires us to write about it we will find the time to put something down. I intentionally avoided many technical details this time around but if that is what you want to read about it can be arranged. Comment, discuss, criticise the word is free, see you next time.

Not a bug, see "Keep finished files in queue" in Queue settings page.

Well yes, it is not like we took every single code change from DC++, we merge the updates relevant to us. SFV checking in DC++ is not a new feature, it was just recently re-added. We did not have the said feature before, when it was still in DC++ in its original form, why would we automatically include it now. That said I am all for reconsidering said feature.

I assume you are referring to IPGuard, we will eventually provide a plugin for similar purposes but it might take a while.

Unfortunately there is no way to say whether a client that states certain tag is actually that client... it is info that is extremely easy to spoof and in no way reliable identification. What mek said above is most likely the best advice that can be given, look for constants in the users in question. Also like BM stated 112 hubs is quite a few for example... I would guess that any regular user client in that many hubs is quite heavy on resources by comparison. I would advise for any hub owner regardless of having a problem like this or not to impose a max hub count that is reasonable. We have things like DHT these days anyways (although it is not ideal for LAN environments. DC network doesn't lend itself well to trying to be connected to large quantities of hubs anyways, users should learn to look for the hubs with content or people they like and stick with those and shuffle the hubs from time to time.

Regarding the original problem, ports can be left open by upnp in the event of a program crash... which may result in further attempts at forwarding through upnp to fail. That said it should not cause the error message about port being in use to pop up. This is something that should be resolved by the program, however, for now the best way to go about it would be to access the upnp rules by different method and clean the problematic rules. Alternatively you could look into manual port forwarding.

Yeah, I just realised what those do yesterday...

Heh, it may work... but whatever they provide is not a real TTH (at least not a real TTH for the real directory, because directories can not be hashed in traditional sense), that is not to say you can't assign a some kind of checksum for a directory but it is certainly not a TTH hash that normal DC clients can understand or calculate without specialized implementation. Whatever greylink method is using I dunno, however, like I said creating pseudo hashes for directories has been discussed before but so far there is no consensus of any kind.

TTH for a folder is a technical impossibility... there have been some discussion in regards to folder hashes and the like, but right now anyways, since a directory is not a real file it can not be hashed "for real" thus no hash for directory can exist.

Use https, not http (yes you will need to add a security exception) As for 32bit vs 64bit... most likely not real difference unless you happen to run a processor that requires the OS to step in and do more of its magics. Google for WoW64 for more info. To put it short to run 32bit application on a 64bit os, the os does a kind of emulation to make that happen... how much of an impact this will have on performance depends what kind of 64bit processor you are running. That said emulation (or we should perhaps use the word compatibility mode) is always a factor that adds more or less overhead. My personal opinion is that you should always run application that is native to your OS if possible, so basically 32bit on 32bit 64bit on 64bit.

Put the attached zip file into your application directory (where ApexDC-x64.exe is). Don't extract it, just place the zip file there. webui.zip

Regarding the message always being the same, that would be because someone was lazy and did not write a unique message to be displayed for each version in the version check file.

Sorry for the inconvenience... it should be sorted now.

Very good suggestion, however, it is going to need some planning... security etc.

No, not intentional... as of right now I am still trying to figure out why is this happening to some people.

It is possible, but not necessarily always 100% accurate.

Same problem was reported with the plugins archive, however, repackaging caused the same result. Also interestingly enough I am able to exact the files fine...

However, it should be noted that often this info is manually set and thus the correctness of it can not be guaranteed.