Switching from Azureus to Deluge

I've always been a fairly happy customer with Azureus, it did what I wanted, it's very fully featured, and highly extensible given the army of plugins available on their sourceforge. However lately I've been wanting some things that Azureus couldn't very easily provide me, so I undertook the task of switching from Azureus to Deluge, without a moment of downtime I might add.

First off, there was the task of actually handling the files, that was simple enough. Make copies of everything in another base folder... done. So I more-or-less copied the contents of my ~/Azureus Downloads folder to the newly created ~/Deluge (not to be confused with ~/.deluge) folder. Then I had to go around finding all the actual .torrents for those files, again fairly simple. A lot of back and forth but ultimately a simple task. Then came my favorite part, the actual configuration.

Configuring a newly installed program is particularly enjoyable to me, and as I got deeper and deeper into Deluge's options I realized that I had found exactly what I was looking for, exactly what I had been missing in Azureus.

For starters, the WebUI is nothing short of spectacular. Azureus's WebUI was only capable of fairly simple things: Starting/stopping torrents, setting speeds, a few options, et cetera. Deluge's WebUI offers damn-near the same amount of options and features that the GTK interface has; It even looks virtually identical. Pretty much anything you can do via the GTK interface can be accomplished using the WebUI. The greatest part about it though? It's live! The data updates every 2 seconds or so, versus waiting a predetermined amount of time (by default 30s) for Azureus' WebUI to refresh the entire interface.

Another great Deluge feature is that it sorts torrents by tracker: something I spent a good chunk of time and effort attempting to do in Azureus. In Azureus I wound up having to create groups for each tracker and having to manually add a torrent to a group every time. Deluge does it for you, which is great for keeping things clean and organized.

Azureus had groups, Deluge has 'labels', however Deluge's labels are capable of being configured to behave a certain way (at least to a higher extent than the settings available to groups in Azureus). That is to say, you can use labels to apply a pre-defined set of rules to any torrent that is a member of the label, things such as dl/ul speed, connection limits, upload slots, autostop, completion moving, and more.

Deluge is infinitely more organized than Azureus was, in all regards. You can sort torrents by tracker, label, or 'state'. There are several different states: all, downloading, seeding, active, et cetera. Downloading shows torrents that are downloading, seeding shows torrents that are seeding, and active only shows torrents that are transferring data in one direction or the other (i.e. no idle torrents). Now by Deluge standards, the only sorting option that Azureus offered was All, very unorganized, very convoluted. If you wanted organization you had to take matters into your own hands by creating groups or something else. Deluge comes with organizational skills by default, and I'm already quite fond of this.

But by far, my favorite thing about Deluge is that it doesn't share the same cache-size limitation that Azureus has as a result of the JVM. Bittorrent is hell on hard drives, so a large cache means less disk thrashing. With Azureus I was able to get my cache up to about 90MB while remaining (relatively) stable. With Deluge, I gave it 65,536 16KB blocks, or 1GB of RAM to play with. I know what you're thinking: 'bloat-city'. I don't see it that way. I run Linux, not Windows so I don't have an operating system that's already sucking down half of my system resources to begin with. I can afford to dedicate a GB of RAM to Deluge alone, because the rest of the system rarely exceeds 512MB of RAM usage, even while operating at higher stress levels than normal. Why let the resources sit there unused?

Deluge is also written in python, my favorite programing language, so I'm looking forward to having a new platform to experiment with.

I do feel obligated to state for the record that I never was unhappy with Azureus, I just wanted certain features and options that were not available to it. Azureus was great to me, and I learned a lot because of it. So I present the final stats from my Azureus installation, who has faithfully served me since day one.

A whole 'nother level of geekdom.

Two days ago, me and two friends spent about 8 hours in my 15 degree garage "linuxing". Box A was a server running the new dual core atom 330, and Box B was an old Pentium IV box. We'll start with Box A:

Debian 5 Lenny (i386) was actually a breeze to install, except when we went to install grub it defaulted to hd(0) which was a compact flash card on the motherboard, removed that, reinstalled (just goes quicker) and it was up and running. Since it had no wireless card, I had previously saved several debian packages to a flash drive for installation (such as openssh-server) and installed them after I spent an hour trying to figure out how to mount the drive. I feel a bit foolish actually, I tried pretty much every argument and every configuration of 'mount', but the reason it was not working was simply because I didn't specify a partition. I typed 'mount /dev/sdb /media/Lexar' when I should have typed '/dev/sdb1'. Got that mounted, installed the openssh-server and openssh-blacklist packages, and powered down the box. Then I took it upstairs and plugged it into the router, configured /etc/networking/interfaces to auto connect to an ethernet connection and removed all the peripherals leaving the server on.

We went back to the garage to work on Box B, which was to become a dedicated bittorrent box, and simultaneously worked on the Debian Box off of my laptop via ssh. The Debian box was to become a CSS (Counter Strike Source) server, so we configured that using the following sequence of commands (obtained from this guide:):

$ mkdir srcds
$ cd srcds
$ wget http://www.cstrike-planet.com/dls/hldsupdatetool.bin (usb)
$ chmod +x hldsupdatetool.bin
$ ./hldsupdatetool.bin
$ chmod +x steam
$ ./steam -command update -game "Counter-Strike Source" -dir .
$ ./srcds_run -game cstrike -autoupdate +maxplayers 20 +map de_aztec > srcds.log 2>&1 &

We then ran the server and checked the logs. Everything seemingly went fine except three textures were missing from the map. It was at this point we gave up for the night so I am unsure as to whether it was that particular map, or if there is a deeper problem at hand. We'll figure it out eventually.

While configuring the Debian CSS dedi over ssh, we also worked on the bittorrent box, which contains a rather ingenious little integration of mine that uses an aim client to add .torrents to Vuze's queue. We installed Mint 8 on the box which took about a year and a half running off the live CD, then installed the latest version of Vuze from their website (version in repos is really outdated. Using Pidgin's autoaccept plugin, we configured an aim account running on Pidgin that would autoaccept file transfers from my friend's screen name and save them in ~/Uploads. Firstly the plugin must be enabled, then on the buddy list you must right click the screename you want to authorize then go to autoaccept and always allow. Next, we configured Vuze to automatically scan that directory (~/Uploads) every 60 seconds for new .torrents, copy them to ~/Torrents, and add them to it's queue. Finally we set both Pidgin and Vuze to launch at login (During Mint 8 install we opted to not require login, ergo when the power button is pressed you are taken to the desktop, not the login window) and voila!

I eventually want to get vnc working on the bittorrent box, as well as actually play a game of CSS on the server but yesterday I was just too tired and wound up laying in bed all day watching a Law and Order: SVU marathon. I'll eventually write up a more complete (with pictures) guide on how to get the Pidgin/Vuze integration too.