STOP Button (Pause is not Enough)

[GoogleCodeExporter]

Currently the only way to "Stop" a torrent is to click the PAUSE button.  THe 
problem with this is that the Pause is still actually connected to the 
tracker(s) and so will update its seeds/leechers from time-to-time.  This 
wastes bandwidth and on a NAS will continually turn on the hibernating drive 
just to make this unnecessary update.  

I suggest you add a "STOP" button alongside the Pause button so that the user 
can actually stop the torrent and by so doing will 0 out the seeds/leechers and 
not be connected to any trackers.  But still keep the torrent content waiting 
to be started again for later.

Original issue reported on code.google.com by core...@gmail.com on 2 Sep 2010 at 5:08

[GoogleCodeExporter]

Pause button send a torrent-stop command to T over the rpc. And T will stop the 
torrent (no download, no upload, and i think no announce). So the button has 
wrong name, i should called "stop" :/

Original comment by elso.and...@gmail.com on 2 Sep 2010 at 5:50

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The strange part is that even if you pause the torrent you still see the 
Seeds/Leecher count changing.  On my NAS drive which has an Auto-sleep when 
there is no activity will turn on every once in a while (5-10mins) because 
Transmission (or the underlying daemon) is waking up my NAS drive to update the 
values.  So technically the Pause is indeed pausing BUT it is NOT stopping the 
torrent.  I can understand the value of a Pause command though...makes it 
quicker to resume a torrent rather than starting from a stop state.

The benefit of having a separate Stop button is that people with external NAS 
drives on a network can finally have torrents that are indeed stopped and 
doesnt wake up the NAS each 5-10 min intervals.

Original comment by core...@gmail.com on 2 Sep 2010 at 7:25

[GoogleCodeExporter]

The RPC call is indeed named torrent-stop, but I think I made it pause because 
of this behaviour you describe.

This project just makes API calls, we can't do anything about what happens 
behind them. If you can find an API call for us to use other than torrent-stop 
let us know :-)

https://trac.transmissionbt.com/browser/trunk/extras/rpc-spec.txt

Original comment by AlanF...@googlemail.com on 4 Sep 2010 at 9:31

• Changed state: WontFix

[GoogleCodeExporter]

I can understand your dilema but there is a simple solution to this problem.  
Since this is an independent app on the Windows platform then why not just 
"remove the torrent" (not the underlying data) from the Transmission queue list 
but set a special flag within a config file on the user's computer which allows 
the app to know to keep it displayed within the transmission app but show it as 
truly stopped.

Now, since the torrent is no longer really seen on the transmission daemon then 
it will be stopped but since the special flag was set in your Windows-specific 
Transmission Remote app then it will still show the torrent displayed in the 
app.  When the user goes to "Start" the torrent it will resend the torrent to 
the dameon and the dameon will start it again.

At least that is what i would do as a programmer based on what you have to work 
with.

Original comment by core...@gmail.com on 5 Sep 2010 at 5:58