Categories
FreeBSD Linux Python

Ubuntu + Python + BitTorrent trouble

I’m wondering if anyone else has experienced trouble with the Python that comes installed with Ubuntu when trying to use the official Python BitTorrent client. (Note that Ubuntu comes with a Python BitTorrent client, but it’s completely different than the official one. Seems like a rewrite. I don’t know its origin.) Anyway, the official btdownloadcurses.py eventually hits some error that screws up the screen drawing, and btlaunchmany.py eventually stops working and begins sucking up 100% of the CPU.

I’ve seen lots of discussion regarding different clients and different OSes with regard to the 100% CPU usage. But I don’t think this is related. Now my intuition told me that the fault lies with Ubuntu’s Python installation. The above problems occur under Hoary and Breezy, and I’m using Python 2.4.2 of the Ubuntu base installation and BitTorrent 4.0.4 downloaded from the BitTorrent website.

So in an experiment last night, I grabbed the sources from www.python.org and compiled my own Python 2.4.2 from source. So far, the official BitTorrent client hasn’t cracked or croaked when running under this Python. So there is something weird about Ubuntu’s Python installation. I wonder what’s different about it.

Update: Well, I spoke too soon. After two days of running soundly, the client gave up the ghost just like before. So, now what? I guess I’ll go back to FreeBSD.

3 replies on “Ubuntu + Python + BitTorrent trouble”

Working with python, perl, and php, I have had limitless issues with reproducing the various authors’ working environments of random imported libraries, and late-bound tools — even before internationalization problems. The tools just don’t have a fine-grained ability to check that the right requirements are available in the right places and the right versions until the binary runs, and flops.

The same issue can very well happen with binaries such as compiled C or C++, because those compiled executables tend to refer to, for example, libcurl.so.1 rather than libcurl.so.1.0.7, so a possible libcurl.so.1.0.4 can cause problems but avoid detection by the runtime linker, but these errors don’t happen. It’s like a mindset difference: the C and C++ stuff just seems to work the same every time as the author intends.

How many people have problems running apache? sendmail? They just work with the same amount of confusion on any platform they are provided for… and their biggest issues are too many configurable options, not random wedging of your runocc%. …but YMMV. Sometimes you have to get experimental when the tools you need are only available in perl, programmed by that guy in Sweden over a few lunch breaks.

Yeah definitely try BitTornado. I’ve built a whole suite of apps around btlaunchmany*.py, currently rewriting btlaunchmany to emit XML. Eventually I think I’ll have it log to an sqlite database to provide historical ratio information.

I run btlaunchmanycurses.py now and have had no issues with it consuming more than its fair share of CPU time.

Leave a Reply

Your email address will not be published. Required fields are marked *