Mek

Please, do :)

In Settings - Advanced - Security - uncheck the first of three checkboxes and then everything should be working.

Aren't they kept in the queue just as any other file?

eheh, sorry, my bad. I was just confused when reading this

use the LuaPlugin and then load the antispam script. I am sure you can find out how to do it here in the forums :)

All download slots taken means that the user you are trying to download from has maxed out his upload slots. The solution is just to wait until a slot frees for you (or find an alternative source of the file).

Yeah, I was discussing this issue before as well. Anyway, as others already wrote, it is impossible to implement any other behavior.

Hosting a hub on LAN is the same as hosting a hub for Internet. Just make sure you are firewalled from the outside connections (usually this is the case if you have a private IP address on your network interface card). As for active connections: you will be active as long as your software firewall doesn't block connections to your DC client.

Technically impossible (at least in NMDC, don't know the situation for ADC). Anyway, you can probably guess that the album with larger mp3 files will have higher bitrate. Again, technically impossible, in DC clients. But some of the hub software can allow sending offline messages using a separate command (for ex. Verlihub can do this if the appropriate plugin is installed). Yeah I can imagine this implemented :)

Try pinging 127.0.0.1 and localhost, see what it says...

not valid? weird... well, try 127.0.0.1 then (it's the same as localhost)

localhost is just an address like any other address so you connect to it when you specify it as a hub address when connecting to a hub. For example, using Quick Connect (Ctrl+Q) you write "localhost" there and voila :)

aaah well, if you are running the hub on your own computer then you should connect to localhost:411 and not the hub's outside address! :)

Yeah, that suggestion was here some time ago if I remember correctly... and well, for now it looks like the hub operators should take care of users sharing such files...

This is likely to be the issue. Or, the TCP port for the hub (most probably 411) isn't forwarded. Or maybe some sort of firewall issue on the hub's side.

I upgraded the same way and everything works.

To check your hard drive use a windows utility named chkdsk. Run it from the command line, for example: chkdsk c: /f (perform this with all your hard drive letters). To check your memory, use memtest.

Then backup your whole Settings folder; your share along with the hashed data (and more) will be backed up.

Not possible to implement. To remedy your problem, I would suggest setting up some sort of QoS on your network, so that voice is prioritized.

Look here. Is it the same problem?

Are you using the correct version (x64) of Apex? Is it freezing with "Not responding" status in Task manager, and then, after some time, it continues as usual, or it just freezes and doesn't unfreeze, forcing you to kill the process via Task manager? Have you tried checking your hard drive/memory for errors?

Nice. But when your torrent transfer finishes, the files are not in your DC share immediately. I mean, there must be a filelist refresh and hashing, first. But how can you force a filelist refresh programatically? (you can do it by pressing ctrl+E manually).

Is it hashing? How many hubs are you connected to? Are there any transfers?

I think this is the new feature which helps segment spread among the users optimally; however, I don't know if it can be turned off in settings, most probably not...

Are your Regional settings in Windows Control Panel all set correctly? If yes, then you should be getting Japanese fonts and everything... other than that, I don't know, just guessing...