Opened 11 years ago

Closed 10 years ago

#2336 closed Enhancement (duplicate)

Better handling of torrents on an external volume when that volume is not present

Reported by: Biiaru Owned by: livings124
Priority: Normal Milestone: Sometime
Component: Transmission Version: 1.73
Severity: Normal Keywords:


I have a problem, and that is that I have a lot of torrents on external hard drives. At the same time, I still have quite a few on my internal drive and sometimes I find myself wishing there was an easier way to tackle the problem of running Transmission while those external drives aren't plugged in.

Right now, as it stands, if a volume a torrent is on is not available, Transmission will pop up a little message on startup that lets you pause or relocate that torrent... and will continue to pop up that little message for every single torrent that is on the unavailable volume. This causes a lot of problems if you've got a lot of torrents, such as I do (1,832 altogether at current count) and this could be easily rectified by having it pop up one window saying "(number) torrents are on an unavailable volume" if there's more than one unavailable torrent.

The other problem is with getting them unpaused after that volume is available again. I'd like to propose that torrents that are paused due to being on an unavailable volume be flagged with that as the reason. Then, if that volume is plugged back in (or powered back on or whatnot) they could be able to automatically unpause and return to seeding or downloading or whatever they were doing. This would solve so many of my problems when it comes to being on a laptop. I'm going to be a college student soon and moving around a lot, and being able to have Transmission running in the background while not plugged into the external drive and being able to have these torrents pause and unpause when need be would make my life a whole heck of a lot easier.

In addition, if a volume is unplugged for some reason while Transmission is open, it doesn't bother to pause them, at least as I recall from previous experiences. It would probably be a wise idea to do this so someone doesn't try and request some data we happen not to have at that moment.

This isn't really a necessity, and shouldn't be at the top of your list, but it might be nice to have in some upcoming major point release or so? 1.8, 1.9, whatnot? I'm sure I'm not the only one that would find this a really useful feature.

Questions and comments and further ideas or suggestions are welcomed. :)

Change History (13)

comment:1 Changed 11 years ago by Waldorf

I don't usually do this, but here it goes: I second this request!

For the third part: If T could listen to unmounts, that would be nice.

comment:2 Changed 11 years ago by Biiaru

I realize I have this marked as being for the Mac Client, but it might be a good idea to implement this in the GTK/Qt clients since I'm sure us Mac users aren't the only ones with this problem!

comment:3 Changed 11 years ago by charles

  • Component changed from Mac Client to Transmission

comment:4 Changed 11 years ago by livings124

#2806 is related, requesting a dialog to select the new location if the current cannot be found.

comment:5 Changed 11 years ago by photonclock

#3198 is related. Seconding the request to present a dialog and better handle the current behavior, particularly when downloading to shared network volumes.

comment:6 Changed 11 years ago by photonclock

Also, I don't really agree that #3198 deserves to be closed as a duplicate of #2336. In #3198, I'm detailing an reproducible scenario where Transmission places files in a hidden and illegal file path as a result of an offline network volume. (Using JIRA where I work, we would classify this a separate related bug, and leave them both open.)

comment:7 Changed 11 years ago by charles

  • Milestone changed from None Set to 2.10

comment:8 Changed 11 years ago by charles

#3224 had been marked as a duplicate of this ticket

comment:9 Changed 11 years ago by Longinus00

This is mostly handled in #2955.

My patch doesn't have any protection against data disappearing in the middle of a transfer but hopefully transmission would error out when it tries to read data that's not in the cache. The patch also doesn't introduce any gui elements but I don't consider that a priority until we're happy with how it works.

comment:10 Changed 10 years ago by Mosstromo

MacOS 10.5.8 Transmission 2.01 (10898)

I have an almost identical problem as Ticket #3198 with the exception that it occurs on an USB External Hardrive and not a Shared Volume over a network. The behaviour is identical though. Worse than getting space used up on my laptop's HD is the fact that when the download of the torrent file is concluded, the "original" download (in the External HD) is incomplete and still sports the extension (.part). The "completed" download (without the .part extension) is inside that invisible Volume on a duplicate of the original folder in my laptop. But this "completed" download is not complete either. The download with the (.part) extension (external HD) is truncated from the point onward where the interruption (power failure or internet disconnection?) took place, and the "completed" download (in the invisible Volume in my laptop's HD) seems to be missing the first part of that same information. You get the picture, divided in two (very likely) corresponding halves. The file is unusable and the torrent must be discarded (since Transmission warns of identical torrents being downloaded) and added once more to the client.

How I checked this:
1) I stopped and removed the torrent from Transmission. 2) Added the torrent once more and selected the path to the original download folder in the External HD. 3) Added to the folder the incomplete file (.part extension) from the External HD. 4) Transmission then checked the file to see how much information was already in existence. 5) It showed less than 30% completion. 6) Stopped then removed the torrent once more. 7) Copied the "completed" file from the invisible Volume on the laptop's HD and added the .part extension. 8) Followed the same steps (2-4) for this file. 9) It showed around 80% completion.

I took the same steps for both "halves" of the file.

Previous to this the seeding still continued normally, even though the files were not full or were "spread out".

I also have a .PNG of that duplicate folder inside the invisible Volume, but it is almost the same as the one uploaded by the owner of Ticket 3198, so I will not upload it.

comment:11 Changed 10 years ago by livings124

  • Milestone changed from 2.10 to Sometime

comment:12 Changed 10 years ago by notgary

comment:13 Changed 10 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

this ticket is already being handled by #2955 in trac and in launchpad

Note: See TracTickets for help on using tickets.