the forums at degreez.net

It is currently Sun Jul 23, 2017 6:41 pm

All times are UTC - 7 hours [ DST ]




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 233 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16  Next
Author Message
 Post subject:
PostPosted: Sun Jun 05, 2005 9:32 am 
Anonymous wrote:
could you possibly add a download speed limit option? when it downloads at max speed it cripples my network, and being able to set a maximum download speed would help a lot



its aqllready there under advanced :max download


Top
  
 
 Post subject:
PostPosted: Mon Jun 13, 2005 11:00 am 
system tray suggestion

as the icon turns white when a download finishes, id also like to see the icon be either green, yelloe, blue, or black so you can see the status of your torrent while its still in the systray

an addon to this would be when green, yellow or blue the icon becomes a brighter shade as the dl speed increases an option to set the color to say like 100kb/s would mean the color would become its brightest at that dl speed

this could also be done to show upload at the say time by say, spliting the icon in 2, left shade shows upload speed, right shows dl speed

either way im really just looking for a way to get more infromation about the torrent while leaving it in the systray, the simple color change would be the most effective and i belive the simplest as the others would most likely wast memory/cpu

eitherway, i love tornado, keep up the great work


Top
  
 
 Post subject:
PostPosted: Thu Jun 23, 2005 6:00 am 
Suggestion:

My upload speed = 14 kb/s
My DL speed = 140 kb/s

lets make a http version of the client that we can put it on a free intaweb host
or
lets add a " http - link - feature" wich would allow to add http sources to the torrent file wich would be distrebuted under all the ppl
only need to crypt the file with a key(like the M$ bt copy will do) and maintain that we dont have to upload the whole file just like 30 mb or 50 mb of the whole file depends on the free host ....
that would be a nice tool


Top
  
 
 Post subject:
PostPosted: Sat Jul 16, 2005 10:14 pm 
Bittornado and bittorrent in general needs to be more friendly to those on slower connections.

I'm thinking things like:
-auto beginning and ending of downloads (say at startup)
-auto dialing/reconnecting in the case of a disconnection
-auto shut-down of pc when a download finishes or just stops
-preference to download files in sequence (when possible) rather than every file at once... (I know this is already somewhat implemented but it needs more automation - with a torrent of say, 5000 files, you aren't going to manually choose them in order)

Just more automation in general; for those who have to leave their pc's for a week to get any decent sized file....! :roll:


Top
  
 
 Post subject:
PostPosted: Tue Aug 30, 2005 12:57 am 
Disclaimer: I've not read all the posts in this thread.

It would be cool if you could set the client to end a download after a certain ratio or amount of data uploaded has been reached.


Top
  
 
 Post subject: LINUX!!!
PostPosted: Wed Aug 31, 2005 8:11 am 
It would be really nice for bit-tornado to be able to work on Linux.


Top
  
 
PostPosted: Fri Sep 16, 2005 7:20 pm 
Did a simple search through the sources, and noticed that BitTornado doesn't use mmap().. So, I'll make that my request: Add mmap() support :D

It's fairly simple and works mostly like normal fd object, but needs some tricks when working with empty files.

http://www.python.org/doc/2.4.1/lib/module-mmap.html

It should improve read/write performance on Windows and *Nix platforms (don't know if others support mmap(), but it shouldn't be too difficult to skip mmap() on those).

And I'm quite sure this hasn't been requested before, unless someone used the longer name in their post.


Top
  
 
 Post subject:
PostPosted: Thu Sep 29, 2005 10:20 am 
Since alot ISPs are throttling p2p traffic nowadays, why not implement encryption on the packets' headers? This way, traffic shapers won't be able to identify the traffic as p2p and thus, bypassing them. BitComet had implemented this feature in its latest version.

But for BitComet, the encryption thing will only work if 2 parties are using the version that supported it. Maybe, BitTornado can use the same header encryption protocol or method. Then BitTornado and BitComet users can connect to each other using the encryption. :D


Top
  
 
 Post subject:
PostPosted: Fri Oct 07, 2005 4:13 pm 
Wishlist :
1) Support for UDP trackers ! http://libtorrent.sourceforge.net/udp_t ... tocol.html
2) Have a real bug tracking / wishlist system. Host your project on Gna! Savannah ! GForge, SourceForge, or whatever...
3) Have multiple instances of BitTornado share a common upload cap
4) A lot of work on the GUI, but you probably already know about it


Top
  
 
 Post subject:
PostPosted: Thu Nov 24, 2005 7:13 pm 
15 pages is a lot to read.
but i'll just voice my opinion, and you guys can ignore it if it has been mentioned.


Unicode for torrents other than English. Because I keep having to use BitComet to download Chinese torrents and i really dislike BitComet actually.

other than that, that's it.

thanks


Top
  
 
 Post subject: Pre-allocation
PostPosted: Sat Nov 26, 2005 12:39 am 
Considering how slow pre-allocation is, I think you could improve its performance by using ftruncate() call and not doing whatever you're doing now (which I presume is simply writing out a lot of junk to the files until they're of correct size). This is sadly Mac/Unix-only improvement, so Windows users wouldn't benefit from it.

Relevant documentation: http://www.python.org/doc/2.4.1/lib/os-fd-ops.html

And yes, you can increase the size of the file with that. Not only decrease, or completely zero its size.

And yes, I could write a patch for it myself, but what little I've tried understanding how - or rather where - things happen in the Python-based bittorrent clients, I've been so far, quite unsuccessful.

Another note: You could probably "pre-allocate" with sparse files by seeking to the end of the file (outside the current file size) and writing a single garbage byte there. The file would still be sparse, but at least the system would "know" how large the file's going to get, and hopefully avoid file fragmentation with that.

P.S. This should probably be forwarded to Bram..

--
Maoh
The Perl, Python, PHP and C++ newbie


Top
  
 
PostPosted: Sat Nov 26, 2005 12:44 am 
The client currently seems to get stuck when the disk partition runs out of space.. So, I'd like it to have some nicer behaviour here. Possibly configurable to either flush out what the client has so far and exit cleanly, or wait for space to free up.

So far, the client seems to either get stuck completely (prompting it to be killed by external means) or exit, but I'm unsure how cleanly it does that.

If this is already implemented, then I'd like the frequency of the space checks to be configurable, or at least stated clearly somewhere so I would know when it's going to try doing something again.

--
Maoh


Top
  
 
PostPosted: Wed Dec 07, 2005 9:21 pm 
It could be neat with a more extensive use of multiple colors in the progress bare to indicate the status of the torrent. I imagine something like this:

BBBBGGGGGGGGGGGYYYYYYYYYWWWRR

Blue: Parts you've downloaded, but currently not seen online.
Green: Parts downloaded and available online.
Yellow: Parts not downloadad but currently available.
White: Parts currently not available.
Red: Parts not seen at all since download started (requires that Bittornado keeps share stats between sessions).

This would make it easier to judge whether a torrent is dead or just a bit slow, and also where seeding is needed most.

Axel Eng
Oslo - Norway


Top
  
 
 Post subject: Re: Pre-allocation
PostPosted: Mon Jan 16, 2006 3:21 pm 
guest wrote:
It would be really nice for bit-tornado to be able to work on Linux.


You're kidding, right?

Anyway.

Maoh wrote:
Considering how slow pre-allocation is, I think you could improve its performance by using ftruncate() call and not doing whatever you're doing now (which I presume is simply writing out a lot of junk to the files until they're of correct size). This is sadly Mac/Unix-only improvement, so Windows users wouldn't benefit from it.
...
Another note: You could probably "pre-allocate" with sparse files by seeking to the end of the file (outside the current file size) and writing a single garbage byte there. The file would still be sparse, but at least the system would "know" how large the file's going to get, and hopefully avoid file fragmentation with that.


The thing is, Linux, and I would guess most UNIX-like OS's (including Mac), handle things like sparse files transparently (and competently). With "normal" allocation -- which I think on Linux is the same as "sparse", and really not much at all -- what you describe in your last paragraph is exactly what happens. The first part. Sometimes. If / when it happens, you'll have, say, a 700MB file, empty but for a few MB at the end (or in the middle, actually) that only takes up a few MB on disk. If another few MB are written somewhere else, the filesystem allocates some space, not necessarily anywhere near the first, and writes the data there. The filesystem keeps track of what goes where and where nothing has been written, and the file remains small (on disk), but fragmented. So bittorrent's normal allocation can end up with chunks written all over the place, giving highly fragmented files. To avoid this, (I think) the prealloc method *has* to write some garbage the entire length of the file. I think. In any case, it probably writes a few MB at a time to prevent too much fragmentation.
For a sparse file, the system may "know" the full file size, but I don't think it can do much about it. In theory, it could put the 1MB-at-the-end-of-the-file at the end of a large unallocated space, and then reserve that space. But then if that space never gets written to, that space would be wasted, unless the fs had some half-allocated state that expires after a while or something else that is hard, or non-deterministic, or not useful in the general case (and not useful enough to be made a special case).

This is getting long. :) But I'm done with that, and don't have too much else to say.

I don't know much about mmap (and more in theory than in practice), but if it's whole-file, and I think the Python one is, it could only be used (or be useful) with small files. ...er, maybe not. I guess in theory you could mmap the whole disk and let the kernel figure it out. The system mmap can start anywhere in the file, but it still seems like if the program is just filling up an array and writing it, mmap wouldn't be terribly useful. It might save a copy or two in memory on read, but that probably wouldn't make much difference. Maybe it could make some code cleaner / easier. I don't know.

The disk full issue is annoying; a few times I've let it run - er, hang - all night after forgetting or not noticing the disk was low on space. I doubt many programs handle it gracefully, though; I'd expect most to just crash, either with or without saving open files. BitTornado just seems to hang, though. I don't know why. It may just be stuck in a loop trying and failing to write to a file, but I don't think clearing up space gets it unstuck, so it might be stuck somewhere else. It would be nice if it woke up and continued when space became available, and at least upload in the meantime. ...that was the annoying part; seeding one thing and some other thing fills up the disk. *hang* ...at least it doesn't hang everything when it can't open (or write?) a file for some other reason. That got really annoying. And is why I switched back from the original client after trying it for a week.
Maybe disk space status could be in the client somewhere, so you'd have some warning (if you're paying attention). ...or at least have a bar to watch shrinking as stuff gets downloaded. whee.

(So much for not much left to say. :))


Top
  
 
 Post subject:
PostPosted: Tue Feb 07, 2006 1:54 am 
I'd like to see more advanced features in bt*curses, well, actually everything that is in gui like download details, possibility to change what file to download first etc, manual announce, external anounce, details about hwo and what amount has down/uploaded from/to us, ability to pause downloads. Especially in btlaunchmanycurses I'd like to see pause on selected download.


Top
  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 233 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16  Next

All times are UTC - 7 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group