BitTorrent/FeaturesThatWouldBeUseful

• Ability to queue multiple downloads
  

btdownloadmultiple (headless gui and curses) exists in cvs, not in the main pack yet though, I don't think.  --Vitenka

• Ability to quit after a download has finished, possibly specifying a time to wait first
  

Note: [ABC] (short for "yet Another BitTorrent Client") does both of these now.  It also supports having a default downloads directory - so clicking torrents from webpages becomes zero-interaction, so you can go "click torrent 1, pause, click torrent 2, pause, click torrent 3" to enqueue three torrents.  It will quit one download and start the next in the queue after either a certain time or a certain share rating.  It seems rather nice from the time I've used it.  --AlexChurchill

And rather unstable when we tried it on a friends machine (tried to add more than one torrent, ABC locked up).  --Tsunami

*blinks *shrug* YMMV, I guess... --AlexChurchill

However, it is currently running fairly happily on my machine, with several torrents queued up ready to grab :)

Yes.  That would be useful.  How about after the total amount uploaded equals the total amount downloaded (and 100%)?  Shouldn't be a terribly hard patch.  --Vitenka

Sounds good. Shouldn't take terribly long after a download finishes, either, since the clients do tit-for-tat anyway. The two features together would allow one to script downloads; for instance, I could arrange to automatically fetch new episodes of anime when they appear in the trackers. - MoonShadow

Well, not as long as there are still other clients downloading the file.  You probably want a time limit too though, otherwise you will sometimes get stuck never finishing just because no-one else wants the file from you.  --Vitenka

Already in.  People who download from you but do not upload to you are not scheduled for download again.  It's a basic part of the system.  Of course, once you have 100% of the file then you allow leeches (because, like, duh, you're no longer downloading anything from anyone) and you also sometimes optimistically unchoke (schedule some fragments for someone who isn't uploading to you) so that people who don't yet have any of the file can get started.  You can't work out whether people are uploading to people who aren't you - such a thing would either be susceptible to cheating or would cost more bandwidth than it saves.  --Vitenka  (Short answer - it already does enough - if you do more then no one would ever be able to download anything.)

Then it doesn't work properly. I have seen huge amounts of traffic while downloading a file, but none of it coming in my direction, even with several seeds. You sure there are no clients out there that have gotten round the anti-leech protection built in?

There's no 'getting round' to do.  They send you a block, you send one in reply.  Unless you've got spare uprate in which case...  hang on.  I bet I know what it is.  If you are on an asymetric connection (and you almost certainly are) then you need to set the --max_uprate parameter.  If you do not, then it will max out your connection - and choke out your clients ability to ACK the incoming bits - effectively choking off your download.  Set it to about 90% of your actual uprate.  --Vitenka  (Note, the experimental cliet, if you google for that, lets you set uprate from the gui, which is much easier)

Quick addendum - it does take a while for the download rates to settle down.  After all - you have to send full blockjs to other clients to prove to them that you're not a leech.  --Vitenka

OK, currently I am looking at some 5 peers and 32 seeds for the file I am downloading. I have set the upload to slightly less than the max upload for the cable modem (10kb/sec), however the upload speed rarely ever gets as high as the limit. Still, I have been lucky to get more than 1-6Kb/sec download speed. With some 32 seeds, how come this is so slow? (still, my share rating is very good! ^_^) --Tsunami

Humm - I don't know.  I'd suggest playing with maximum number of peers to see if that helps.  I can only presume that something funny is happening.  Of course, it could be that the particular file you are torrenting is being served up by a bunch of scruffy modem users...  First thing to do is make sure that you have the latest client (from cvs) - while the wire protocol hasn't changed, newer clients are a lot more efficient.  Second is to set upload to *realistic* upload.  That is, the level of sustained throughput you can get to another server.  Dropped packets mean dropped download.  This includes making sure it's not being used by anything else.  And finally, cross your fingers and offer a sacrifice to eris.  --Vitenka (sorry, all I can say is that it works wonderfully for me)

• Incorporate wget into it.  Make it much more like GetRight? or other download accelerators.  Though it would ideally need a means to automatically locate other download sites, and torrents from the url of a file.  (Mainstream acceptance issue I guess)