Closed GoogleCodeExporter closed 9 years ago
Also - Provide a option (e.g. "Multi-Torrent Limit" text field in "local
settings" dialog) to set the global concurrent torrent transmission limit. The
value of this field (default "0" = unlimited) defines the limit of concurrently
downloading/seeding torrents.
All additional torrents in a "started" state remain in a "paused" state whilst
this threadhold is satisfied.
Provide a option (e.g. via "Autostart Torrents" checkbox in "local settings"
dialog - disabled when "Multi-Torrent Limit" = 0) to autostart torrents, in
currently "paused" state (probably in selected indexed order), when the number
of
concurrent torrents becomes less than "Multi-Torrent Limit".
This functionality would allow the user to "queue" a number of torrents with
the
knowledge that they will all be processed automatically at a controlled rate
that
suits the concurrency limitations of the users infrastructure.
Original comment by chodberry@gmail.com
on 19 Mar 2009 at 11:22
I'll keep this ticket open and see how I feel about doing it when I have more
spare
time. For now, I'm really busy with my last term of uni.
I hacked together something simple like this a while back just using cron, the
command line client and a small amount of shell scripting. I'd post it, but I
can't
find it anymore.
Really, this would be far better implemented on the server side and
configurable from
the client...
Original comment by AlanF...@googlemail.com
on 20 Mar 2009 at 11:00
Agreed - it would be more elegant for this to be implemented perhaps as part of
a
server side scheduling component; but it's also sometimes nice to have a more
distributed implementation - especialy when a transmission server is running on
especially low spec'ed hardware.
Given that many transmission users will not want any further footprint/working
set bloat for anything other than core functionality, it may be that in effect,
this can only be built on the client.
However - ignore this for now and finish your last term of Uni! Then fix it :-)
Original comment by chodberry@gmail.com
on 21 Mar 2009 at 12:24
Seed ratio limiting is coming to Transmission 1.6 I think (see
http://trac.transmissionbt.com/changeset/7888). Transmission remote would just
need
to allow to configure the server setting.
Original comment by mirael...@gmail.com
on 25 Mar 2009 at 1:25
Nice! Thanks for letting me know, I'll certainly support this at some point.
Original comment by AlanF...@googlemail.com
on 25 Mar 2009 at 2:34
some troubles with the download/upload limiter:
i set both to 100kb/s and works fine.
but when is set the upload limit to 1000kb/s, download limit automatically set
to the
same limit.
so the download limit must set manual back to 100kb/s.
Original comment by 0obeanon...@gmail.com
on 23 Apr 2009 at 9:34
Weird.. I tried a few times to reproduce this (using a recent svn of
transmission)
but wasn't able to. I'm pretty certain this would be a server side issue, since
I
can't think of any reason that the difference between 100 and 1000 would cause
this
behavior in my code.
Although, I've thought this before and been wrong so I'm not completely ruling
it
out. :-)
If you want to check, try this tool. It's a HTTP debugging proxy that will
allow you
to inspect the HTTP requests and responses.
http://www.fiddler2.com/fiddler2/
Original comment by AlanF...@googlemail.com
on 27 Apr 2009 at 2:08
You are right Alan!
I have this bug only on my rootserver (lenny 5.1|transmission 1.51) on my
homeserver
it works fine (lenny 5.1|transmission 1.40).
Furthermore thanks for the link.
Original comment by 0obeanon...@gmail.com
on 27 Apr 2009 at 3:08
Seeding ratio limits are implemented now. As for autostart paused torrents,
I'll only
support this if it's a remote setting in Transmission.
I have a bandwidth allowance between 4pm and 12am, so I just use these crontab
lines.
Google cron if you don't have a clue what I'm talking about.
0 0 * * * /usr/local/bin/transmission-remote -t all -s -n alan:pass
0 16 * * * /usr/local/bin/transmission-remote -t all -S -n alan:pass
Original comment by AlanF...@googlemail.com
on 26 May 2009 at 4:24
Original issue reported on code.google.com by
chodberry@gmail.com
on 19 Mar 2009 at 11:08