air

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?

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.

Мелкомягким не понравилось, что проги имеют доступ на запись в папки друг друга и таким образом способны модифицировать друг друга. Поэтому доступ на запись в %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.

1. /me in nmdc-hubs is now treated raw info string or command of sorts. It appears to be bold green style, dubs itself to hub status string and even actually written to hub status log. Everything is okay with adc-hubs. CDM: Hub: [Outgoing][-.-.-.-:411] <AirstrikeD> /me ping| Hub: [Incoming][-.-.-.-:411] * AirstrikeD ping That is what it looks like: 2. Some built-in /commands that use /me to spam something in chat (e.g. /ratio) are broken in adc environment (again?). Haven't tested nmdc hubs though. CDM: Hub: [Outgoing][88.147.128.10:10000] BMSG IJXP ping ME1 Hub: [Incoming][88.147.128.10:10000] BMSG IJXP ping ME1 Hub: [Outgoing][88.147.128.10:10000] BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB) Hub: [Incoming][88.147.128.10:10000] BMSG IJXP /me\sratio:\s9,03\s(Uploaded:\s3,92\sTiB\s|\sDownloaded:\s444,51\sGiB) Hub: [Outgoing][88.147.128.10:10000] BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s Hub: [Incoming][88.147.128.10:10000] BMSG IJXP /me\suptime:\s17\shours\s24\smin\s22\ssec\s What it looks like: 3. Despite this quite uncanny knack of forcing /commands to use adc-compatible /me instead of oldschool +me in this version, /w still uses +me by default. 4. Last but not least. Before the update i was having an entire drive for file exchange and storage purposes. So i had it share-enabled with some folders (e.g System Volume Information) disabled. Well, after upgrade i noticed the most of my share is gone and then i figured out that if i re-enable disabled folders or if i disable the drive and then enable only the folders supposed to be shared - my share becomes normal again. So i put my shared folders in another folder, unchecked the drive and then checked the new folder. I would like to know whether it is a bug or an undocumented restriction to share entire drives or anything else. I could even reproduce and printscreen it some other time if you'd need this.

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.

Both confirmed. And no exceptioninfo.txt generated in my case. This is the old one crash i've noticed in 1.2.0, alas it seems to be still not fixed. Rightclick version happens with any folder my cursor comes in touch with.

You can't use 1.2.2 from now on since it can be hacked (and it even shows an annoying message about it every time you are in the web). I assume NAT on your router is already set up. So set the bind adress to 192.xxx.xxx.242 (i suppose it is static), delete your wan ip, uncheck ip updater, uncheck Don't allow hub/UPnP to override, press OK, search for something. If search fails, try disabling your firewall or set up some bypass rules for apex in it, set to direct connection, search again. If still fails, set up passive mode.

5. Well... From 1.2.2 (or maybe i turned on something wrong in settings) while using the automatic alternative search technique apex not only tries to perform a successful TTH search but also tries to download some filelist chunks from clients that provided responds to that search to browse these filelists in background in order to match queue. And due to various reasons (e.g. having an awfully set up apex speedmod legacy client with some cheats enabled) some guys can't upload their filelist to me. So then the transfers tab becomes filled up with some dozens of Connecting...â

5. Literally nothing happens when 'close connection' of transfers' rightclick menu option is chosen on incoming filelist transfers (green colored ones) while the client states to be 'connecting...'.

Preferencesâ

I second that. It would also be nice if it could be downloaded via update checker - or even downloaded and auto-installed via dht.

1. Before 1.3.0 the result of '/me ping' has been looking like it still does in adchpp or in uhub. The adc variant of /me is on the second screenshot. And i'd like to add that current nmdc-style /me is looking this bold and green like a system message in every nmdc hub i've laid my fingers on, be it different versions of ptokax, or be it dbhub, or even be it verli. 2. Anyways i suppose that blaming the parser is better than blaming oneself. It keeps his self-esteem at a decent level and this way preserves his sanity and mood in a good shape. =) 4. No messages. After pressing okay to close the prefs I just notice the filelist update gets started, then gets finished and then i see 120+ gb instead of 760+ and have a filelist without the folders that make up the missing 640. Then i create a new folder, physically move the share there, uncheck the drive and check the folder with my share in it - no indexing occurs, i press okay again and see my 760+ gb back online.

Now it goes with some "every DHT firewall check" flavor. However, i don't know how it should work since DHT is disabled by default.

Apparently user commands added in 1.2.2 are still ok, visible, clickable and working, but what topicstarter said is clearly reproduceable. More than that - if adding one new 1.3.0 user command to 1.2.2 ones, all of them become expelled from user commands subsection of e.g. user menu. Subsequent removal of this new one did actually restore visibility and functionality of the old ones. Edit: forget about that, i was looking at the wrong hub. BTW Why can i use user commands in nmdc hubs only?