For now, please look at the FAQ (available in English, German, and French) on the project homepage.
If you have to use a http proxy server for web access and want to make the GUI use this proxy server whenever you fetch new serverlists via http, set the environment variable 'http_proxy' before you start the GUI from the shell (=command line):
export http_proxy=http://wwwcache.somehost.net:8080/
Note the slash at the end. Other programs like wget and lynx will honour this
setting as well if the variable is set. You can check if the variable is set with
the echo $http_proxy command.
The best thing is probably to put the above export-line at the end of your ~/.bashrc file, then you don't have to type it in every time you start the GUI, but the environment variable 'http_proxy' will automatically be set every time you login.
This means that after completing a part of the file, the checksum ('partial hash') of the this part of the file on your harddrive does not match the checksum that it should have.
This is nothing to worry about. eDonkey/overnet has realised the problem and will download this part again.
Data corruption just happens. There is nothing you can do about it. Don't worry about it. However, if this happens very very often with many different files, there might be some hardware problem on your side (faulty RAM, faulty harddrive, faulty controller, faulty IDE cable, problems due to overclocking, overheated system, problems with the filesystem, etc).
By default, the GUI will search for a browser on your system and use the first it can find (of Galeon, Konqueror, Mozilla, Netscape, Opera). If you prefer a specific browser, then you should set the environment variable 'BROWSER' before you start the GUI from the shell (=command line):
export BROWSER=/usr/bin/konqueror
You need to specify an absolute path to the binary. You can find out this path by using
either the whereis konqueror or the which konqueror command (note:
which might not always find your binary because it has hard-coded paths).
The best thing is probably to put the above export-line at the end of your ~/.bashrc file, then you don't have to type it in every time you start the GUI, but the environment variable 'BROWSER' will automatically be set every time you login.
The latest GUI version lets you 'preview' ongoing downloads before they are finished if your core communicates the x.part temp filenames to the GUI (all recent versions should do that) and if your core is running on your local box.
If you run the 'preview' function for the very first time, the GUI will write a default
preview shell script to your harddrive. This preview script is located at ~/.ed2k_gui/ed2k_gui_preview.
You can open it in a normal text editor and customise it according to your own preferences.
Here is how it works: The GUI will call the script and will pass the location of the partially downloaded file
to the script as parameter. In the script this appears as $* (which basically just means 'replace with
all parameters that I got'). The GUI will also set the environment variable ED2K_PREVIEW_EXTENSION to
contain the file extension of the file in lower case (as you can't really easily tell what type of file it is from
a name like /mnt/temp/34.part).
Now the script takes the file extension and looks if it matches any of the preconfigured cases in the case-
statement of the script. If it does match, then the variable PREVIEW_BIN is set to contain the name of the
program that should be used to preview this file, including any parameters for that program. Then the program for
the filetype is run. As you can see it's dead easy to change your favourite player or add new extensions.
After the preview program has stopped, you will need to press the Enter key in order to close the xterm window which has been opened to show the output of any preview programs (and that lets you interrupt previewing with Control-C, for example in the case of mpg123/ogg123).
If you do not want the script to wait after a preview has finished, remove these two lines from the script:
echo "Finished. Hit <enter> to close this window"
read
If you want the xterm window to close right away after calling the preview program, remove the two lines above and modify the line calling the preview program like this:
$PREVIEW_BIN "$*" &
Please refer to the section on ed2k-links in the 'Usage' chapter of this documentation.
TODO, see FAQ
If this is in filenames or servernames, then this is probably due to your selected locale. You need to figure out how to change your locale to something appropriate. If you change your locale anyway, please do change it by all means to use the UTF8 charset, and not ISO-8859-X (e.g. de_DE.UTF8 or similar).
However, both eDonkey2000 and Overnet are completely locale un-aware, in the sense that they do not tell the GUI or other clients in which character set a string was encoded. So you will never really be able to see a filename within the search results exactly the same way that the other person sees it with any other person in any language. This should not be a big problem though usually.
TODO, see FAQ
Why? I don't know. Possibly a GTK+ bug. Go to the options page and make sure the 'disable double-click in lists' option is set. That should solve your problems.
The 'preview' function of the downloads list right-click pop-up menu is disabled in two cases:
(1) no items are selected
(2) the GUI thinks that the core is running on another computer. The GUI will assume that this is the case when you are using a differen hostname/IP than 'localhost' or '127.0.0.1' as the hostname of the core (note: more sophisticated checking for local interface addresses/hostname has been disabled due to user requests). So for now everything that is not 127.0.0.1 or localhost is non-local.
Problem: You can only configure your router to IP-forward a port to exactly one IP address, so the other boxes can't use the same port and have a high ID.
Solution: Run each donkey client on a different port (e.g. one on 3662, one on 4662, one on 5662, one on 6662, etc.), and configure your router to IP-forward each port to the right IP. Note: you only need to forward one tcp port per client in order to get a high ID.
You might have multiple cores running that you want to control either at the same time or at different times. In this case you probably want to use the '-n' command line option of the GUI, which will run the GUI in another 'instance', meaning that it will use a completely different set of GUI configuration files. For the first core, just start the GUI normally. For the second core, pass the '-n 2' option to the GUI. This way your statistics etc. will be kept clean and separate and you can also configure the GUI to auto-connect to the core in question on startup.
This is a problem. A core can only be controlled by one GUI at a time.
However, there is an easy and free way to solve this problem: use VNC.
Install a VNC server on the machine where the core runs, and VNC viewers (available for all kinds of platforms) on the systems where you want to control the GUI and the core from. Now run the GUI on the machine where the core runs, and remote control the GUI on that machine using VNC. One VNC desktop can be shared by multiple users, so this should solve your problem. In theory at least, as I haven't tried it myself yet.
This is my (Thomas) starting script for the donkey, as I was tired of changing to the correct dir manually every day... It fetches a fresh serverlist, starts the core, waits and then starts the GUI.
#!/bin/sh # E-Donkey 2000 Starting Script # Start the donkey from its home dir, replace this with your donkey directory! cd ~/ablage/edonkey # Get server list, try to be tricky mv server.met _server.met wget http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-max.met || cp _server.met server.met rm _server.met # Start eDonkey in a named screen session (You need GNU screen!) screen -dmS donkey -- ./donkey - ! # Otherwise: # ./donkey - ! & # Wait a little... sleep 5 # start GUI ed2k_gui -c
Usually you can just start programs with a '&' at the end in the shell and they will happily run in the background. With the eDonkey command line client, however, this will not work properly. You might have a similar problem if you want to start the donkey from a telnet/ssh (don't use telnet, use ssh!) session, but keep it running even if you log out. 'nohup' doesn't work with the donkey on many systems either.
For this kind of magic you need the 'screen' utility, which is probably already installed on your system. Check out
the man page with man screen>. Here is the summary:
Start the donkey with
cd /home/joe/ed2k/
screen -dmS donk ./donkey0.50.1 - !
The 'cd' is to make sure that the core reads and writes its config files always from/to the same directory (i.e. /home/joe/ed2k/ here). If you don't do this, the core will write its config files to the current working directory, which will probably cause confusion at some point.
The '-' option is to put the donkey in GUI mode, and the '!' option is to make the donkey accept commands only via the GUI, but not from the command line, which you need in order to shut down the core properly from the GUI.
Leave the screen by first pressing Control-A, then Control-D. You should be back in the shell now.
You can go back to the donkey screen at any time with
screen -d -r donk
then.
This can have multiple causes. Note that 'firewalled' is not to be taken literally. 'Firewalled' simply means that the other server could not successfully connect to your client on the configured client port (which is 4662 by default).
One reason why this could happen is that you are really running a firewall, either on your computer, or on your gateway/router, and that firewall blocks the incoming connection attempt from the server.
Another reason could be that you are using a DSL router or some other router/gateway, and this router does NAT (= Network Address Translation = IP Masquerading = Internet Connection Sharing/ICS). NAT is used so that multiple computers on a small private network can share one internet connection. In this case the 'public IP' from your ISP is assigned to your router, and all your computers on the private network get a 'private IP' (e.g. 192.168.x.x or 10.x.x.x). If this is the case, you will need to configure port-forwarding on the router. You will need to forward tcp port 4662 to the IP of the computer where the donkey is running. If you have multiple donkeys running on your network, run them all on different ports and configure port-forwarding for each of those ports to a different private IP.
Finally, some servers are misconfigured and do not allow outgoing connections to non-standard ports. These servers will always tell you you are firewalled, even though they are firewalled, and not you. This is likely to happen occasionally if you run your donkey on a different port than the standard port (tcp 4662). However, if really all servers tell you that you are firewalled, then this is not likely to be the cause of it.
Unfortunately the current command line client does not support a SOCKS proxy server, but you could try using tsocks, which will provide SOCKS proxy support for programs that don't have that natively. (It does that by means of a pre-load library that intercepts the network system calls to connect() and 'redirects' it to a socks proxy etc.).
You might find that after running the donkey for a while your internet connection seems to get horribly slow, or at least very unresponsive: connecting to a webserver or checking your e-mail suddenly takes a couple of seconds instead of a couple of milliseconds.
First off: if this can be reproduced with specific servers independent of whether the donkey is running or not, then the problem is likely to lie elsewhere. If you are using PPP-over-Ethernet (PPPoE) then you should double-check your network interface's (pppX or ethX) MTU settings (as an example). If the problem only occurs when the donkey is heavily uploading, read on.
Here is the problem in a nutshell: your DSL router has a built-in packet queue, which works quite simple: the first packet that comes in goes out again first (FIFO). If the packet queue on your router is full, then the router will just silently drop packets. This is a normal thing to happen, and the TCP protocol deals with that. The problem is that for each TCP packet that you receive your computer needs to send a small acknowledgment (ACK) packet to the sender so the sender knows that the data arrives. This mechanism is used to compensate for lost packets and adjust speeds dynamically with respect to the available network bandwidth. Now if your router's packet queue is filled up because of the donkey's upload and you want to connect to a websever, then the connection request (SYN packet) gets sent to the router, which will put it into its queue. But if the queue is full, it will take up to a couple of seconds until that SYN request is actually sent out to the webserver you want to connect to, because your router usually can't distinguish between important and unimportant packets. And the same thing is going to be repeated for each other packet that you send out (e.g. the HTTP-GET request from your web browser). That's why things get sluggish. What you need to take into account is that even if your upload line speed is technically 128kbps = 16kB/s (as an example), some of that is used up by administrative information (headers) of the various protocols involved. So your effective upload line speed is lower, and your upload can easily fill up even if it looks like it is safely below the upper limit.
What to do?
Quite simple: you want something called Quality-of-Service (QoS). Later 2.4.x Linux kernels have this stuff already built in, you just need to make sure that your kernel has been compiled with full QoS support (in-built or as modules).
The principle is simple: make sure that router's packet queue never fills up. In order to achieve this, you want to queue all packets that need queueing on your Linux box instead of on your router (note: this will usually not happen, because the connection between your linux box and the router is so much faster than the one between the router and the rest of the internet, so the linux kernel will usually just send everything out to the router immediately and without delay). Now that the packet queue is administered by your linux kernel, you can tell linux to do all kinds of neat things. For example, you can tell it to give some packets priority over others. Then those packets will 'jump the queue' and be sent out immediately even if other (less important) packets are waiting in the queue. Personally, I have marked all traffic to the 'interactive' ports 21,22,23,110 (but not 80 because many windows people configure their donkey to use port 80) and all traffic to my favourite websites and all 'small packets' (SYN or ACK packets usually) with the highest priority.
A good description by Emmanuel Roger of how to set up this stuff can be found here: http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html.
From my own experience I would advise you to stay clear of other HOWTOs (like the ADSL-Bandwidth-Management-HOWTO), unless you want a challenge. This and most other HOWTOs that I have found on this issue require you to patch your kernel source and your iptables source (e.g. for the IMQ-device), which proves especially difficult if the patches mentioned there don't work with the latest kernel/iptables releases....
Here's a snippet from my iptables start-up script, in case anyone is interested:
##########################################################
#
# Quality of Service (QoS)
#
# from http://www.prout.be/qos/QoS-connection-tuning-HOWTO-4.html
#
##########################################################
# reset
tc qdisc del dev eth1 root 2>/dev/null > /dev/null
# mark packets with size 0-500 (considered interactive traffic)
#
iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3
# mark UDP packets as important as well
#
iptables -t mangle -A OUTPUT -p udp -j MARK --set-mark 3
# bigger packets will be marked data traffic
#
iptables -t mangle -A OUTPUT -m length --length 500:1500 -j MARK --set-mark 4
# mark ssh/smtp/pop3 packets also as priority
# (not http, due to many donkey people using port 80)
for i in 22 25 110
do
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j TOS --set-tos Minimize-Delay
done
# mark favourite sites high priority traffic.
#
# slashdot(new) slashdot.org, www.ct.heise.de,
# edonkey2000, jigle.com, jabber.org
# google
#
for i in "66.35.250.150" "64.28.67.150" "193.99.144.71" \
"198.77.34.120" "212.249.10.246" "208.245.212.108" \
"216.239.39.101"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j TOS --set-tos Minimize-Delay
done
# mark whole subdomains important
#
# amazon/imdb - sourceforge.net
#
for i in "207.171.166.0" "216.136.171.201"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j TOS --set-tos Minimize-Delay
done
# create root cvq qdisc for our device eth1
#
tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64
# DL bandwidth = 576 kbits
# UL bandwidth = 288 kbits
#
# Interactive class rate = DL bandwidth / 20 = 29
# Data class rate = UL bandwidth - Interactive class rate = 259
#
# Let's make the latter a bit smaller just to be on the safe side
# (we don't want a single packet ever to be queued on the router)
# => 190, which is much lower than suggested, but works best wor me
#
# (1500 is interface MTU?)
#
tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit \
rate 29Kbit allot 1500 prio 1 maxburst 10 avpkt 100 isolated weight 100
tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10Mbit \
rate 190Kbit allot 1500 prio 8 maxburst 2 avpkt 1500 bounded weight 1500
# tell kernel which class we want to send packets to
tc filter add dev eth1 parent 10:0 protocol ip handle 3 fw flowid 10:1
tc filter add dev eth1 parent 10:0 protocol ip handle 4 fw flowid 10:2
That seems to happen with the recent cores. The reason ist most likely that eDonkey/Overnet use too many file descriptors (one filedescriptor for each open file and each active network connection), that is more than you as normal user joe are allowed on your system.
You can check with
%ulimit -n
the number of open file descriptors your user is allowed in total (taking into account all programs and processes that you are running currently).
You can change that limit by editing the file /etc/security/limits.conf (as root) and adding a line like this at the end:
tim hard nofile 4096
'tim' is the username you are using, 'hard' stands for 'hard limit', 'nofile' stands for the number of open file descriptors allowed, and 4096 is the value (you might want a higher value, but 4096 should be fine).
Now you need to check one more thing, which might be slightly different from distribution to
distribution. If you have a file /etc/pam.d/common-session, then make sure you have a
line like this in it:
session required pam_limits.so
If you do not have a file like this, add or uncomment the above line in /etc/pam.d/login.
If you use gdm/kdm/xdm to login, then you should check whether /etc/pam.d/gdm,
/etc/pam.d/kdm, and/or /etc/pam.d/xdm have this line and add/uncomment it if required.
After you've edited that file, you need to re-login 'properly' (log out from X and re-login on the konsole or xdm/kdm/gdm). After that if you run 'ulimit -n' in an xterm window, it should display the new limit and the problem should be solved.
On Mac OS X the default limit is apparently 256 file descriptors per user. This is way too little for eDonkey2000/overnet. You can change this limit by typing
limit descriptors 4096 (this is MacOSX tcsh!)
on the command line and then starting either the GUI or the core from there (this is because this setting is only inherited by child processes that you start, it doesn't change system wide). You can check your limit by typing 'limit' on the command line. (Thanks to anonymous nobody in forums for this).
The exact procedure might depend on your system/distribution. Let me know if this needs to be solved differently on other systems.
For one, did you pass the '-' command line options to the core when you started it? The '-' command line option tells the core to listen for a GUI on the specified aport. Without passing it, the GUI will not be able to connect to the core, therefore the GUI only checks for a running core that has this flag as a command line option.
Secondly, the GUI expects the core binary to be called 'donkey*', 'overnet*', or 'cdonkey*' (it only cares about the beginning of the name). If you renamed the program, the GUI will not find it (how would it?).
Two easy solutions: Either use one of the other non-localhost IPs of that box, for instance the IP of your network card (e.g. 192.168.0.2), or edit your /etc/hosts file and add an line like 'core.outerspace.world 127.0.0.1' and put 'core.outerspace.world' into the hostname field of the 'Connect to.."-dialog.
This is an issue that is unlikely to be 'fixed', by the way, because the decision to insist on a locally running core in case of 'localhost' has been made on purpose, namely in order to facilitate joe average newbie user's getting-started procedure.
Please also note that the the 'running core detection' only works on GNU/Linux with a mounted /proc filesystem at the moment. Users of other Operating Systems (e.g. *BSD, MacOSX) might want to send a patch to fix this :)
In Overnet the default TCP port is 4662, and the UDP port used is chosen randomly on start-up. You can, however, make overnet use a fixed UDP port with the 'uport' advanced command. Type '!uport 9876' without the apostrophes into the toolbar entry, and check by typing '!vo' whether the setting got saved. After that, overnet should use the same UDP port every time. You should forward the TCP port (4662 by default, or different if configured differently) and the UDP port after it has been set to a fixed port.
In eDonkey2000, you only need to forward the TCP port (4662 by default).
See if you can reproduce it and/or how to reproduce it.
Check whether the bug has already been reported, and if yes, if it has been fixed already. Make sure you look at 'all' bugs in the bug-tracking system, otherwise you will be shown only the open bugs, but not the fixed bugs.
If you know how to use CVS, please check out the latest GUI version from CVS to see if the bug is still present in the CVS version.
Submit the bug to the project's bug-tracking system with as much detail as possible. If you have a sourceforge account, please log in so that I can get back to you if I have further questions about the bug. Otherwise, please monitor the bug or check back from time to time to see if there are more questions.
Write me an e-mail. Positive feedback always makes me happy :-)
Also, I've now got an amazon.co.uk wishlist and an amazon.de wishlist in case you feel like getting me a small something for the millions of hours of work I've put into the GUI and the core ;)