(on Wikipedia)
http://www.bittornado.com/

A hacker’s BitTorrent client.

I had used this for a while, but using something like it is a bit frustrating for me. It’s rarely updated and is lacking a number of convenience features.

I was thinking of hacking some solutions to my grievances when I just got frustrated and dumped it to try Deluge again.

Abandoned: As of 2019-11-21, version 0.3.18 was released on 2006-12-24.

2010-04-18 – 0.3.18 on Unity Linux rc1 64bit
(earlier than 2009-04-03) – Deluge replaces BitTornado (on my desktop).
2009-03-23 – T-0.3.17 on Slackware 12.2, updated 2009-07-16.
Earlier notes on PCLinuxOS (version not recorded)

Table of Contents [hide]

1 Usage
2 2010-04-18 – 0.3.18
3 2009-03-23 – T-0.3.17
4 Earlier notes

Usage ∞

Basics ∞

A guide for using it: .. there is no documentation explaining how to use it. Sigh.

python  btlaunchmanycurses.py  ./  --max_uploads 3  --max_upload_rate 15  --max_download_rate 100  --saveas_style 2

or you can run it headless (like on startup):

nohup  python  btlaunchmany.py  ./  --max_uploads 3  --max_upload_rate 15  --max_download_rate 100  --saveas_style 2  >>  /dev/null

You can’t know when the file has been completely downloaded without using the status script below.

Whatever file(s) are downloaded by this torrent will emerge when they have completely downloaded.

It’s messy that completed downloads appear in the same directory.

I set up an rc.local entry for it:

/home/user/bin/BitTornado-CVS/btlaunchmany.py \
  /home/user/working/in/BitTorrent/mixed  --max_uploads 3  --max_upload_rate 15  --max_download_rate 100  --saveas_style 2

It works just fine. The unfortunate thing is that the new files which are created are owned by root. I can manually solve that though. More on that next.

checking the status of a headless btlaunchmany ∞

This is possible thanks to Bryce’s bt status viewer with ncurses, aptly named btstatus.

First you have to run btlaunchmany.py with logging enabled. I append >> /var/log/bittornado.log like so:

/home/user/bin/BitTornado-CVS/btlaunchmany.py \
  /home/user/working/in/BitTorrent/mixed  --max_uploads 3  --max_upload_rate 15  --max_download_rate 100  --saveas_style 2  >>  /tmp/bittornado.log

Then I run the status checker:

./btstatus  /tmp/bittornado.log

But now the problem is dealing with this ever-enlarging log file! I just make an hourly cron job. It’s a script in /tmp/cron.hourly of any name, with this:

cp  /dev/null  /tmp/bittornado.log

It’s messy, but it works.

btstatus is a PIG on resources, so only summon it if you’re really curious. You REALLY should nice it like so:

nice  -n 19  ./btstatus  /tmp/bittornado.log

I personally set up a hotkey to summon btstatus in a nice xterm window. It works very well.

Start on bootup

I appended this to my /etc/rc.d/rc.local (rc.local):

(ncurses)

# BitTornado BitTorrent client.
# BitTornado will log events.  This is for bryce's bt status viewer with ncurses to use.
#   www2.bryceharrington.org:8080/drupal/node/67
# But with logging enabled, you have to manage the logfile so it doesn't get too big.  I did this with a simple hourly cron job:
#   cp /dev/null /tmp/bittornado.log
rm /tmp/bittornado.log
su - user -c '/home/user/bin/BitTornado-CVS/btlaunchmany.py /home/user/working/in/BitTorrent/mixed/ --max_uploads 3 --max_upload_rate 15 --max_download_rate 100 --saveas_style 3 --max_files_open 16 >> /tmp/bittornado.log &'

Fix aggressive logging using a ram disk ∞

For me, I use LILO. There is a separate solution for any unfortunate GRUB users. The block in my /etc/lilo.conf (lilo.conf) looks something like this:

image=/boot/vmlinuz
  label="sda1"
  root=/dev/sda1
  initrd=/boot/initrd.img
  ramdisk=10000

That “ramdisk” line is just a 10MB ram disk. Don’t forget to run lilo after making this change. Don’t reboot yet, also complete the below instructions.

Then with my rc.local (rc.local), I added this:

umount /tmp/RAMDISK/
rm -rf /tmp/RAMDISK/
mke2fs /dev/ram0
mkdir /tmp/RAMDISK/
mount /dev/ram0 /tmp/RAMDISK/
rm -rf "/tmp/RAMDISK/lost+found/"
chown user:audio /tmp/RAMDISK

I start BitTornado in my rc.local with:

su - user -c ' \
  /path/to/btlaunchmany.py \
  /path/to/BitTornado-torrents/ \
  --saveas_style 3 \
  --max_files_open 16 \
  --max_download_rate 200 \
  --max_uploads 3 \
  --max_upload_rate 20 \
  >> /tmp/RAMDISK/bittornado.log &'

I made a /etc/cron.hourly/cron.hourly.sh with:

cp  /dev/null  /tmp/RAMDISK/bittornado.log

Reboot once you’ve edited all these files.

Note that I assume that the BitTornado log doesn’t go past 10MB within one hour. Technically it could/should be tweaked to be a dynamically-resizing ramdrive, but I’ve no clue how to go about doing that.

Getting info on a torrent ∞

You can do with this:

\xterm  -fn 9x15  -bg black  -fg gray  -sl 10000  -geometry 113x46+0+0  -e "nohup python /home/user/bin/BitTornado-CVS/btshowmetainfo.py %s | leafpad"

(xterm · Leafpad)

UNKNOWN – Log rotation ∞

Make /etc/cron.hourly/manualrotate.sh with this content:

FILE=/tmp/bittornado.log
TEMP=/tmp/temporary.$PPID

tail -n 100 $FILE>$TEMP
mv $TEMP $FILE
rm -f $TEMP

TODO – update this with an ‘if exist’ clause.

Then:

chmod +x /etc/cron.hourly/manualrotate.sh

FAILS!! The file gets stuck at the same size, but my disk space is being eaten. I guess $TEMP has something to do with it.

I can see the file there, and it’s getting bigger:

lsof | grep /tmp|grep bittornado.log

I don’t see anything else interesting..

lsof | grep /tmp|grep temporary.

In this case, the solution is to kill the process, blank the file and restart the process. Sigh.

BUT, what you can do is blank it out like so:

cp /dev/null /tmp/bittornado.log

2010-04-18 – 0.3.18 ∞

New crypto means I can add this stuff:

 --crypto_allowed 1 --crypto_only 1 --crypto_stealth 1

Seems to be working fine.

2009-03-23 – T-0.3.17 ∞

Seems to work just fine. I re-used the previous stuff compiled under PCLinuxOS.

Earlier notes ∞

It’s also in the PCLinuxOS repository, but I tested it from a download. I checked, and the repo version is the same.

It sure could use some colour.
It’s not interactive at all.
- Instead of letting me cursor up and down to see the list, it auto-scrolls and wraps. Very strange.
It once crashed on resize in an xterm terminal.
I’m not sure how to make certain files stop uploading, or to set a ratio level or the like..
I so want to have separate torrent, downloading and completed directories. It’s so very very messy right now.
- You can’t know when the file has been completely downloaded without using the status script.
- TODO – Moving completed files (not torrents) to separate directory
  — I suggest implementing this in an external script that retrieves file completion via xmlrpc. Then it can either hardlink or symlink the files to ~/Finished, and replace the entire directory structure later when the torrent completes.
  — TRANSLATION: Check the watcher script and see how it can determine if a file is completed (and colour it differently) then make my own script (in a cron job?) to scan the working folder and process completed torrents in whatever way. Maybe move the file out but symlink it back in so it can still be seeded?
I’d love to be able to save files as TORRENT_NAME/proper_name.ext
Seems to choke on many files and just stops working.. I have to cap the number of open files.

General verdict: Not bad, pretty simple but powerful. Takes up bunches of CPU power when downloading lots of stuff.

Has a bad memory issue – 64 megs is about average for a few torrents, but if you download a lot of stuff for a while, and then remove some stuff down to just a few items it’ll go well past 300 megs!

spiralofhope

BitTornado