air

Before my last post DHT was allocated to port 4999, and then i set it to 24999 just to check out if my firewall is the culprit. Alas, i was still having those messages in statis log while KIS was completely shut down. Other ports were TCP/UDP/TLS 5001/5002/5004 and 25001/25002/25004 before and after connection resetup respectively. The other networking programs in simultaneous use are: icq (5900), steam (4380, 27000-27050), some mmo (5000, 6000, 6900), opera (w/o bittorrent, dunno which ports it really uses), skype (dunno too). Internet connection is ADSL/bridge with ICS enabled to share it to the other pc, which was by the way unpowered for all day.

Mmmmaybe it is so because apex tries to -errrrm- reuse a socket that somehow has not been closed properly in the previous DHT session (or something like this is happening)? How can someone check out his sockets, ports and apps that operate 'em in w7? BTW i have Kaspersky Internet Security which is known to act as a firewall. What if it causes the problem? I really can't think of any other soft that can use the port. I should try switching KIS off and setting some other ports to apex. I'll post back. UPD: None worked for me.

Hi there again. I have an old display with max resolution of 1024x768 and i am experiencing some interesting behavior for ballon tooltips (see screenshot). I have had this behavior since 1.3.0 and maybe earlier (i hadn't tried yet to investigate it though) and this day i became curious of whether it is the normal behavior. The system is w7 7600 x64. By the way, i suppose it may be caused by these system messages: [21:46:28] DHT disabled: Обычно разрешается только одно использование адреса сокета (протокол/сетевой адрес/порт). [21:47:28] DHT enabled again I googled up the 1st message and found out that it has to be the russian "human" version of winsock error 10048 WSAEADDRINUSE. Why does this happening and what should i do to avoid it (exept disabling DHT)? By the way, why can't Apex (or any dcpp-like client) have it's own easier to understand (and, if possibble, fix) way of displaying probable socket error messages?

Мелкомягким не понравилось, что проги имеют доступ на запись в папки друг друга и таким образом способны модифицировать друг друга. Поэтому доступ на запись в %ProgramFiles% они закрыли засчет UAC и админки, а большая часть изменяемых программных файлов хранится теперь в %Userprofile%/AppData. Имхо сомнительное решение, но все равно приятно, что теперь есть хоть какая-то защита от дурака.

Фишка с Store settings per user account нужна для того чтобы избавить юзеров от необходимости выставлять апексу админские привилегии в висте и 7 для обхода ограничения UAC на доступ к записи в %ProgramFiles% и %ProgramFiles(x86)%. Проще говоря, теперь в висте и семерке можно без дополнительного геморроя сохранять hashtable и опции. Единственное что не переносится при апгрейде на 1.3.1 - это местоположение папки временных закачек, это делается пока руками. Насчет зависаний - напишите багрепорт, и в следующей версии это исправят. Что вы имеете в виду под "не ищет в результатах поиска при поиске"? "Too many open hubs, max is 4" - не клиентская фишка. В клиенте вообще не стоит ограничений на количество хабов. Трахайте мозг владельца того хаба, к которому подключаетесь с таким эффектом, или переходите на клиенты, которые делают фейковые теги - вы их уже назвали.

Skype does not minimize to tray either. Most programs that able to are either daemon-like (hence they have no main window somehow) or can't use jumplists. Bawww. Since some tray icons can be always visible, it's a pity that lots of great programs can't have jumplist compatibility and tray minimizing ability at the same time.

Since I've moved to win7, how can I possibly detect or guess the matter of similar library conflict when suddenly the same situation occurs and no exceptioninfo is generated? I'm from Russia, but I still don't like the idea of uninstalling half of my system in russian roulette style to guess which program causes apex to shut down in such a speechless manner.

Never ever tried to compile a .chm, but well... I could look for it.

Turned it on. What kinds of messages does it filter exactly? Side note: apexdc sure needs an offline guide with every option explained.

Okay. Now I got it. Excuse me my rudeness. So... How about to implement a workarond to stop hubs' being a smartass? And regarding 6. Can you give me some extra clues?

When I tested this with some decent effort in 1.3.0 this was happening in different versions of ptokax (0.4.1.0 and 0.3.5.2), in dbhub, and in verlihub. Both four hubs I've connected to seemed to give the client the string started with some stars, and then my nick. Stars quantity depends on hubsoft, in most cases there is one or two. Apex adds 3 additional stars and a space before the post and renders it bold green. And when I was using some 1.2.x apex on the same hubs (and I know at least dbhub and verli of the above hubs definitely have not been updated, vastly reconfigured or enhanced with some new hot ass plugins) - NMDC hubs' /me looked absolutely like it was in ADC and like it does look in ADC now. And it definitely has never been dubbed in status field/status log like it still does not in ADC. I also tested oldstyle +me 5 minutes ago on that dbhub I am speaking of and my +me is bold, starry and green too. If it was +me->/me behaviour change to blame then I think +me would perform flawlessly. It ain't. So I just have no other option but to think that something is wrong in apex. I still can get 1.2.0 and 1.2.1 and test it too if it is necessary.

Moved to windows 6.1.7600 x64 two days ago and then today updated to 1.3.1 x64. So... 1. Me still gets correct oldschool parsing of /me posts in ADC hubs and incorrect system-message-like parsing of /me in NMDC-hubs. Hubsoft only changes the number of *** before the message. Could anyone please at least make /me look similar ways in ADC and NMDC? Addendum: this also happens with /me-using /commands like /r 6. Found in 1.3.0 x64 that SID/CID conflict messages (like "xxx (sid1)has same CID (cid) as yyy (sid2), ignoring") are not only posted in status field but also rendered in chat like the system message from the above, which is not supposed to be happening because apparently this "ignoring" flood was fixed in 1.3.0 x86. This bug is still actual for 1.3.1 x64. Screenshots will be added some time after, if needed.

This happened like 10 seconds after running 1.3.1 x86 on xp for the first time after the upgrade. One hub was opened, no active uploads, one active download, 41 GiBs share, user says nothing special has been done at the moment. Crash did not reproduce itself till this moment, however i figured out is should not be bad to notify you guys.

You're a lucky guy, no version of apexdc had ever been perfect to me. Although 1.2.1 was sooo close to be. Regarding your filelist - afaik a temporary solution for you is to lower the level of complexity of your folder tree in your share to meet the xml nesting requirement of 16.

Muchas gracias on that.