WMU-6500FS - Deluge 1.1.5

I just finished a build of the deluge 1.1.5. It is bit outdated (the 1.1.6 version is out now) but I had to solve some problems along the way which taken more time than expected. Once it was finished I did not find a morale to step one bugfix version further.

Build result

[binary] [file list]


The same as for the previous version plus:
[patched python socket module] [tar 1.22] [bzip2 lib]


If you have the deluge-1.1.0 installed, you have to clean it up first (while preserve all the dependencies).
Stop the deluge daemon if it is running. You can do it via console:
box# deluge --ui=null
>>> halt
>>> quit

or forcibly:
box# killall deluged
Now uninstall the previous version:
dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.1.0
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.1.0 locally at /mnt/C (y/n)?y
If you are not using the filopack packaging system, you can remove the previous version as follows:
box# cd /mnt/C/
box# wget http://filodej.ic.cz/filopack/.filopack/deluge-1.1.0.lst
box# xargs rm -f < deluge-1.1.0.lst

Update the system

Before we start installing the new version, we have to update the tar archiver. The one which is part of the busybox has an ugly bug corrupting file names in long paths.
box# ./filopack.sh --download bzip2-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package bzip2-1.0.5 from http://filodej.ic.cz ...

Length: 191 [text/plain]

Length: 40,244 [application/x-tar]

box# ./filopack.sh --install bzip2-1.0.5
box# ./filopack.sh --download tar-1.22
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package tar-1.22 from http://filodej.ic.cz ...

Length: 1,523 [text/plain]

Length: 625,455 [application/x-tar]

box# ./filopack.sh --install tar-1.22

For details about the bug see this section.
Also it may be necessary to download a patched version of python socket library, you can test your system as follows:
box# python -c 'import socket; print socket.gethostbyaddr("")[2];'
Segmentation fault
... if you encounter the segfault, it is better to download and install the patched python socket library:
box# wget http://filodej.ic.cz/filopack/_socket.so

Length: 116,767 [text/plain]

box# mv sys/lib/python2.5/lib-dynload/_socket.so{,.backup}
box# mv _socket.so sys/lib/python2.5/lib-dynload/
Now the problem should be fixed:
box# python -c 'import socket; print socket.gethostbyaddr("")[2];'
For details about this issue see this section.


After we updated the system we are ready to install the new version:
box# ./filopack.sh --download deluge-1.1.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package deluge-1.1.5 from http://filodej.ic.cz ...

Length: 89,430 [text/plain]

Length: 16,084,717 [application/x-tar]

box# ./filopack.sh --install deluge-1.1.5
Sure to unpack deluge-1.1.5 locally at /mnt/C (y/n)? y

Run daemon

Now we are ready to try the daemon, still it is necessary to use the LD_PRELOAD prefix or deluged.sh script:
box# deluged.sh
That's all. Following text just describes details related to the issues I solved. Nothing for ordinary users ;-)

Busybox tar bug

When I run the deluge client (console version) some commands was not properly interpreted:
box# deluge
>>> info
 * unknown command: info
>>> help
 * unknown command: help
I found out that any command is implemented in a separate python file:
box# cd sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg
box# ls deluge/ui/console/commands/
add.py          config.pyc   debug.pyc       help.pyc        __init__.pyc    quit.pyc    rm.pyc
add.pyc         connect.py   halt.py0000755  info.py0000755  pause.py        resume.py
add.pyc0000644  connect.pyc  halt.pyc        info.pyc        pause.pyc       resume.pyc
config.py       debug.py     help.py0000755  __init__.py     quit.py0000755  rm.py
... it seems there are some ill-named files in the command directory, and so the console does not know the commands at all.
Let's find all such corrupted files:
box# find . -name *0000*
Let's look also in the deluge tar archive:
box# tar tjvf deluge-1.1.5.tar.bz2 | grep 0000
-rw-r--r-- 0/0     21100 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/core/preferencesmanager.pyc0000644
-rwxr-xr-x 0/0      1079 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/quit.py0000755
-rwxr-xr-x 0/0      2299 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/help.py0000755
-rwxr-xr-x 0/0      1125 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/halt.py0000755
-rwxr-xr-x 0/0      5296 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/info.py0000755
-rw-r--r-- 0/0      2036 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/add.pyc0000644
-rw-r--r-- 0/0     13688 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/torrentdetails.pyc0000644
-rw-r--r-- 0/0      7346 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/queuedtorrents.pyc0000644
-rw-r--r-- 0/0     13073 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/filtertreeview.pyc0000644
-rwxr-xr-x 0/0      5062 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/page_decorators.py0000755
-rwxr-xr-x 0/0      3233 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/torrent_options.py0000755
-rwxr-xr-x 0/0      1553 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_handler.py0000755
-rw-r--r-- 0/0      1522 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_render.pyc0000644
-rwxr-xr-x 0/0     20480 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/webpy022/db.py0000755
-rw-r--r-- 0/0     38041 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/Label-0.1-py2.5.egg0000644
-rw-r--r-- 0/0      2982 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/webuipluginbase.pyc0000644
-rw-r--r-- 0/0       699 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/checking16.png0000644
-rw-r--r-- 0/0       595 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/inactive16.png0000644
At a first glance it seem that the archive is corrupted but when I tried the same operation on my mirror system (on the PC) no corrupted file appeared in the archive.
The difference was that while on the mirror system I have the GNU tar 1.20 installed, on the box there is a busybox version containing tar utility:
box# which tar
box# ls -l /bin/tar
lrwxrwxrwx 1 root root 7 2008-05-21 13:40 /bin/tar -> busybox
I decided to build the newest GNU tar version (1.22) and install it to the box. A new post containing the build procedure will follow. After the installation the problem disappeared.

Socket related crash

I am not sure whether it was new to this version, but after the installation from time to time I have experienced a weird crash of the deluge daemon. Also the Windows client did not respond for long time when was connected to the daemon running on the box. After some experimenting with the deluge log I decided to debug the daemon to find out what is going on.
I was running the gdbserver on the box:
box# LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" gdbserver colinux:2345 `which python` `which deluged` -d
Process /usr/bin/python created; pid = 31831
Listening on port 2345
Remote debugging from host
Then I was ready to connect to the gdbserver from my mirror system:
deb# gdb `which python`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux-uclibc"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) target remote storage:2345
Remote debugging using storage:2345
0x40000c90 in ?? ()
(gdb) cont
After some time when I was connecting and disconnectiong the windows client to the daemon the problem appeared:
[New Thread 32801]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32801]
0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
108             size = strlen(str);
It was at the following stack:
(gdb) where
#0  0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
#3  0x40094bd2 in PyCFunction_Call (func=0x405ac70c, arg=0x40f2f48c, kw=0x0) at Objects/methodobject.c:108
#4  0x400dcf1a in PyEval_EvalFrameEx (f=0x81f8624, throwflag=0) at Python/ceval.c:3573
#5  0x400de1e6 in PyEval_EvalCodeEx (co=0x405b94e8, globals=0x405b624c, locals=0x0, args=0x820022c, argcount=1, kws=0x8200230, kwcount=0, defs=0x405be518, defcount=1,
    closure=0x0) at Python/ceval.c:2836
#6  0x400dd6d0 in PyEval_EvalFrameEx (f=0x82000e4, throwflag=0) at Python/ceval.c:3669
#7  0x400dda59 in PyEval_EvalFrameEx (f=0x81e77d4, throwflag=0) at Python/ceval.c:3659
#8  0x400de1e6 in PyEval_EvalCodeEx (co=0x405c13c8, globals=0x405b602c, locals=0x0, args=0x406200b0, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2836
a crash in PyString_FromString seems to be just a consequence, let's look up a bit:
(gdb) up
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
3048                            tmp = PyString_FromString(*pch);
(gdb) list
3044            /* SF #1511317: h_aliases can be NULL */
3045            if (h->h_aliases) {
3046                    for (pch = h->h_aliases; *pch != NULL; pch++) {
3047                            int status;
3048                            tmp = PyString_FromString(*pch);
3049                            if (tmp == NULL)
3050                                    goto err;
3052                            status = PyList_Append(name_list, tmp);
(gdb) print h
$1 = (struct hostent *) 0xbb9fdae8
(gdb) print *h
$2 = {h_name = 0xbb9f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbb9f9aec}
(gdb) print h->h_aliases
$3 = (char **) 0x40172891
(gdb) print *h->h_aliases
$4 = 0xc7c3815b <Address 0xc7c3815b out of bounds>
... It seems that a host entry should contain an array of strings - aliases - but this array is apparently corrupted - it causes a crash of the C string -> Python string conversion routine. Let's look who is responsible for filling the array:
(gdb) up
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) list
3268            PyThread_acquire_lock(netdb_lock, 1);
3269    #endif
3270            h = gethostbyaddr(ap, al, af);
3271    #endif /* HAVE_GETHOSTBYNAME_R */
3272            Py_END_ALLOW_THREADS
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
3275            PyThread_release_lock(netdb_lock);
3276    #endif
3277            return ret;
The gethostbyaddr seems as a good candidate. At first I wondered whether the function is thread safe (see the following text about uClibc thread safety), but after further debugging I have found out that the apparently thread safe variant gethostbyaddr_r is called in my case, so there should be not threading issue there.
(gdb) cont
[New Thread 1024]
Breakpoint 2 at 0x407e574c: file /usr/local/src/Python-2.5.2/Modules/socketmodule.c, li
Pending breakpoint "socket_gethostbyaddr" resolved
[New Thread 19476]
[Switching to Thread 19476]

Breakpoint 2, socket_gethostbyaddr (self=0x0, args=0x40f27ccc) at /usr/local/src/Python
3229            if (!PyArg_ParseTuple(args, "s:gethostbyaddr", &ip_num))
(gdb) next
3252            Py_BEGIN_ALLOW_THREADS
(gdb) next
3255            result = gethostbyaddr_r(ap, al, af,
(gdb) next
3272            Py_END_ALLOW_THREADS
(gdb) print buf
$12 = "À¨\001eè\232?½", '\0' <repeats 16 times>, "filodej.doma\000.in-addr.arpa", '\0' <repeats 16333 times>, "@"
(gdb) next
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) print *h
$14 = {h_name = 0xbd3f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbd3f9aec}
(gdb) print h->h_aliases
$15 = (char **) 0x40172891
(gdb) print *h->h_aliases
$16 = 0xc7c3815b <Address 0xc7c3815b out of bounds>
... after some googling I found some hints in the following forum.
Actually it seem there were two related bugs: the first in gethostbyname_r seems to be fixed now, steps to simply reproduce the problem:
box# python -c 'import socket; print socket.gethostbyname_ex("wh0rd.org")[2];'
... it was ok in my case, it seems to be fixed in 0.9.27 version.
The second bug is in gethostbyaddr_r function. The step to reproduce is following:
box# python -c 'import socket; print socket.gethostbyaddr("")[2];'
Segmentation fault
... it crashes on my box. Given you have the Python installed, you can test your configuration the same way.
For the solution I decided not to patch or upgrade the uClibc but rather make a workaround in the python socket library. Zeroing the structure prior to the gethostbyaddr_r call should be enough. Let's modify the python Modules/socketmodule.c file. In the PySocket_gethostbyaddr functon there is a hp_allocated structure we are going to reset to zeroes. Just before the gethostbyaddr_r call we add the following code:
        memset((void *) &hp_allocated, '\0', sizeof(hp_allocated));
        result = gethostbyaddr_r(ap, al, af,
                &hp_allocated, buf, buf_len,
                &h, &errnop);
... and rebuild and re-pack the python package:
deb# cd /usr/local/src/Python-2.5.2
deb# make
case $MAKEFLAGS in \
*-s*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
running build
running build_ext
db.h: found (4, 3) in /mnt/C/sys/include
db lib: using (4, 3) db-4.3
/mnt/C/sys/include/sqlite3.h: version 3.5.8
INFO: Can't locate Tcl/Tk libs and/or headers
building '_socket' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/socketmodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lpython2.5 -o build/lib.linux-i686-2.5/_socket.so
building 'nis' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/nismodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lnsl -lpython2.5 -o build/lib.linux-i686-2.5/nis.so
*** WARNING: renaming "nis" since importing it failed: dynamic module does not define init function (initnis)
running build_scripts
box# make install
deb# cd /mnt/C/
deb# ./filopack.sh -R --pack python-2.5.2

Build process

The build process was identical to 1.1.0 version, I just had to create .pth link file in order to be able to remove the duplicate directories:
dev# cd /mnt/C/sys/lib/python2.5/site-packages
dev# echo "./deluge-1.1.5-py2.5-linux-i686.egg" > deluge.pth

dev# cd /mnt/C/
dev# ./filopack.sh --pack deluge-1.1.5
Remove all the "site-packages/deluge/" sub-paths (they seem to be redundant) and re-pack the package once more.


Christos Georgousopoulos said...

Good work, once again.
I've installed it and it runs pretty cool. Actually it is faster than previous version :-)

Aqualung said...

Dear Filodej, how about you try your exquisite hand at installing and configuring Transmisson please? :-) Deluge looks to me to be too taxing on the box's meager resources...

Many thanks

Anonymous said...

Are you try JKR's Transmission packages (http://mgb111.pradnik.net/)? "Installing and configuring" is very easy: just extract package and make few corrections in settings.json in needed.

Aqualung said...

Dear Anonymous, did you try any of Joker's packages and it worked?? Some of us (e.g. Christos) have been trying them for some time, and it's been impossible to get them configured properly. Granted, I have not tried Joker's latest Transmission release myself, but we would really appreciate some deeper insight as to how you've managed to get it to work. Why don't you post some step by step algorithm please? That would really help!

(As a side note, my Deluge 1.1.0 works reasonably zippy, tough I'd still love to give the latest Transmission a try...)

SingleWolf said...

Yes, it worked :). Maybe you try early JKR's Transmission builds (before 1.6)which really was "hard to use". Now it's easy in installation and more stable in usage. You need only JKR's firmware with packages from "must install" section from included readme and "libs-essential" package.
Installation procedure step-by-step:
1.Extract downloaded package by tar xzf [package-name].
2.Run daemon with transmission-daemon for few seconds to create config files.
3.Stop daemon withkillall transmission-daemon
4.Edit settings.json file in [home-dir]/config/transmission-daemon (change "rpc-whitelist" string to meet your network settings).
5.Run daemon with transmission-daemon.
That's all. Now you can access Transmission web-interface through http://[your_box_IP_or_name]:9091 and configure download directory, incoming port,speed-limits for incoming and outgoing traffic or do that with external clients such as transmission-remote-dotnet or transmission-remote-dotnet.

Aqualung said...

Awesome! Dear SingleWolf, that's really encouraging! Thanks for the effort. Few questions:

1. What is that "must install section" and "included readme" that you're referring to? Do you, by any chance, mean "minimal-config.tar"?

2. When it comes to the "libs-essential" package, which one of libs-essential-090408-v1.tar.bz2 and libs-essential-090408-v2.tar.bz2 should I install? Or should I install them both?

At any rate, just so we do not clog Filodej's blog with such trivial issues, why don't we move our discussion to a proper forum? How about we move our discussion to: http://www.macsat.com/macsat/component/option,com_smf/Itemid,50/topic,780.0/ ?

Many thanks, again.

Aqualung said...

Here's the link again: http://www.macsat.com/macsat/compon

Aqualung said...

[Dear Filodej, many apologies for clogging your blog with unrelated stuff...]

I installed the latest Transmission (1.75.whatever), but all I am getting in terms of web interface is a blank page with the word "TEST." It looks like the transmission daemon doesn't find the web interface files, although I checked and they seem to be in the right place (/sys/share/transmission/web). What am I doing wrong?

SingleWolf said...

Have some troubles with registering on Macsat forum so quick reply here:
1.I mean readme.txt file that included in firmware archive.
2.These packages are almost identical (differs only with tar version), so you can use any of them.

Aqualung said...

Well, I've been running Transmission for almost ten days now, and I must confess that I'm hooked. It's blazing fast, and way zippier than Deluge. I guess I'll be switching to it completely, once I've ironed out all the kinks. So far I've been using only the web interface, and I take it this doesn't unlock all the Transmission functionality, does it? Also, the Inspector "Information" and "Activity" tabs show no information: is that how it's supposed to be?

SingleWolf said...
This comment has been removed by the author.
SingleWolf said...

1. Yes, built-in web-interface has only basic functionality. But you can use another client for example such as transmission-remote-dotnet or transmission-remote-gui.
2. Latest builds has a defective torrent-status reporting code that cause "N/A" marks in web-interface and make clients unusable. Downgrading to transmission-1.74.9092-090910-test will solve this problem for present time (until new build with fixes released).

Aqualung said...

1. Tried Transmission Remote Dot Net, but it doesn't work: it gives me unhandled exceptions. I am running it under Windows 7, though I may try it under WindowsXP as well later today. I even tried it in compatibility mode, to no avail. Will try transmission-remote-gui, see what I get. (I am also wondering whether the issues below might be giving me trouble with Transmision Remore dot net, would they?)

2. The important question is whether it is *JKR's* 1.75 Transmission builds that are at fult, or is it that *all* 1.75 builds have these issues? (I recall trying an earlier 1.75 build by JKR, and it behaved in the same way.)

SingleWolf said...

1.Re-read (2) in my post above. Exception caused by error in daemon responce.
2.Only transmission-1.75.9125-090916-test if you want namely 1.75 build :).

Aqualung said...

2. Okay, so I've tried 1.75.9226 and 1.75.9243. You say 1.75.9125 should work fine: where do I get this one from? Care to post a link? Thanks.

SingleWolf said...

MD5: 7B1F8AF55EC8743825E27D0615639F79

Aqualung said...

Many thanks, works like a charm. I am getting amazing speeds! Let's hope that JKR will keep building newer versions as soon as they are released.

Aqualung said...

Dear SingleWolf, many tanks for your help. I have two more questions about configuring Transmission:

1. I need to ask for authentication/password for accessing the Transmission WebUI. How would I do that? Otherwise anyone can stumble accidentally into my Transmission WebUI, and wreak havoc... Need to ask for some form of authentication. How do I enable that?

2. Not sure how to use the "blocklist" feature. Care to say a few words on that please?

SingleWolf said...

1.RTFM :)
2.It blocks connections from unwanted IP's. By default it downloads a blocklist called "level1" from some organization called Bluetack. But you can write your own blocklist in text file blocklist.txt with this string format:
name:IP_range_start-IP_range_end, put it into ~/.config/transmission/blocklists/ then start daemon. Your TXT should be automatically into BIN and used (when enabled).

Aqualung said...

1. Thanks, but that webpage amounts to pretty much nothing in terms of explanation. At any rate, I take it I should enable "rpc-authentication" right? (How the heck am I supposed to know what that is? There's no explanation anywhere.)

2. As for the blocklist, I take it once I've enabled the "blocklist-enabled" feature, Transmission will take care of the rest, i.e. I don't have to download it myself and place it somewhere specifically etc., right? Also, is there any way I can tell if the blocklist is actually working?

SingleWolf said...

1.Yes, you should enable authentication to get it work:
rpc-authentication-required=true. Also you should set up username, password and access IP (range).
2.I think so, but I never check it because it's a "common" blocklist (globally blacklisted IP's). I prefer use my own one (I use it to switch between local/global seeding).

Aqualung said...

SingleWolf, I don't suppose you could put your blocklist on Rapidshare, could you? I take it that once I have it I'd just have to place it manually in the "blocklists" folder and that would be all, right?

And how can one tell if the blocklist is working?

SingleWolf said...

Yes, I can. But it will be totally unusable for you, because it's specific to my local ISP's rules so I suppose that it simply block ALL your torrent traffic (except IP ranges that my ISP suggest as "local") when activated :). You must write own one, with your specific range.
For example, this blocklist:
will block all traffic, except local IP ranges by RFC1918 and one global range

Nicholas said...

Dear Filodej,
I had indstalled deluge-1.0.5. I tried installing deluge-1.1.0 through filopack.sh but it found the file corrupt, so, I moved to on to deluge-1.1.5 which downloaded and installed great after making the upgrades. However, when running deludged.sh I get: /usr/bin/python: Can't resolve symbol '_Unwind_SjLj_Register'
Any ideas what causes this and how to resolve it?

Thank you,


filodej said...

Hello Nicholas,

few days ago a user Fab asked the same question. It turned out that his configuration (namely LD_LIBRARY_PATH variable) was not set up well.

Please, look at our communication and let me know if it helps.


Christos Georgousopoulos said...

Hello Filodej,

I wish you all the best for the new year to come, full of love, happiness, health and wealth ;-)

One year ago you've helped me a lot on how to setup Deluge (actually I would't be able to do it without you). Now for the new year I would like to ask for a favour ;-) I would kindly ask you to please create/compile the new version (1.2.0_rc5) for us if this is not too much problem for you.

The reason for asking is that the previous version has been banned by some trackers (private ones) due to its old version, and now I cannot seed from the box.

Once again, I thank you in advance.

Happy new year ;-)

Christos Georgousopoulos said...

Hi again,
do not know if your blog is still active, but I just needed to say that I have successfully managed to switch to 'transmission' so there is no point for me to carry on with Deluge. Thank you though for all the support you have been providing us up to now ;-)
All the best, keep up the good work !

Aqualung said...

Yeah, I was going to suggest that (i.e. switching to Transmission) at the time of your previous posting, though it looked to me that you were interested in using Deluge *specifically*, hence that's why I didn't intervene. So yeah, I've been a happy intravenous Transmission user for almost four months now, thanks to SingleWolf--God bless 'im!

filodej said...

Hello Christos,

I am very sorry for the delay. I recently returned from my vacation and now I am catching up on all my backlogs.

I can see on the Deluge site that the full 1.2.0 version is out.
Maybe I'll manage to find some time to build it, but anyway, thank you for letting me know that now, after you have switched to Transmission, there is no hurry in this respect.

Kind regards,