baba.runner

Great work Thx. Got just this little error after install.

There is a just alittle issue with the Toolbars. When the "Lock Toolbars" is checked, then the normal toolbar is locked but not the Mediaplayer toolbar. And when the "Lock Toolbars" is not checked, then the normal toolbar is not locked but the Mediaplayer toolbar is. Just wanted to let you know.

Hi all I got this RTE error message, but ApexDC was still running and when I closed the RTE message box ApexDC closed. I was only in 2hubs and downloading only from 2 sources and 2 uploads run also. One of these uploads started all always again. Unfortunately I can not tell you anymore what has been uploaded how many times as the Upload log was not saved. Let me know what I can give of information! Is the exceptioninfo usefull for you? Let me know and I post it. Cheers baba.runner

Hi all I do not exactly know what happend, but in the evening when I got to my PC I see this on the screen (please refer to the attached image) It happened already twice. Can you please advice What I have to do? Thank you in advance. Kind Regards baba.runner

I voted no on both, as I think that both do belong to the hub part and not to the client part of DC. A Hubowner does not necessarily want that "normal" user can post things on his hub without his acknowledgement. For the RSS-feed, there are other possibilities to have that information. It would be OK if the Feeds were only in relation to APEXDC++ and only visible for the user of the client. And those information are already available here.

Yes, I have it disabled!

try this site and learn.http://portforward.com/

should be something with your Firewall and your ports! Have you tried to search in passive mode?

There are two other settings you should turn off. In the settings -> Downloads -> Queue: uncheck "Automatically search for alternative TTH source every XX minutes" and also uncheck "Automatically match queue for auto search hits"

just type /rebuild in the Mainchat

Just one question. Does the rehash or the rebuild also consider the temp files, the *.dctmp files? As it are those files whoa re having this tth inconsistency. btw: I am not able to reproduce this with the new build .475. and when I change back to 1.1.0 again , I have directly the TTH inconsistency.

TOAST I do not know how to explain but I can reproduce this behaviour. See the picture attached. I used the /rebuild after having the TTH inconsistency. and after a while , after some reconnection I have it again. I also need to say that I have 0B in my share!!!

I did not say that I did not rehash my share, neither i did confirm that I did But the TTH inconsistency is what the client is showing us in the download area. This does not mean that the TTH code is buggy. Please try it out yourself. download a big file from an other user and when you started downloading it, make simply a reconnect in that Hub (make sure that the download is interrupted) and tell us if you get a TTH inconsitency notification when your client tries to continue the download. Thx in advance.

But that is no solution you proposed. It is a workaround, yes. You can not force all user to rehash everytime the user from which you download, is making a reconnect.

I can confirm this behavior with TTH inconsistency. When a download is going and the user from who you are downloading disconnect and reconnects afterwards, the file could not been completed as the error due to TTH inconsistency appears on that file. The only way to finish this file is to delete it and to start it again. The search for alternatives doesn't help neither. It will find other users but the TTH inconsistency is not resolved.