Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#1017 closed Bug (duplicate)

Handle situation where local data isn't found due to unmounted media in a nicer way.

Reported by: andersos Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.83
Severity: Normal Keywords:
Cc:

Description

I got hit by this today. I had verified all my torrents with latest svn rev yesterday. This morning I boot my pc and start transmission (GTK) client (without thinking :D). I have all torrents on USB disks, which I forgot to mount before transmission start. So transmission didn't find any local data and apparently reset the .resume files, so now I have to verify all torrents again.

It would be nice if this could be handled in a better way. The simplest way would be to show a message about what happened and then let the user decide what to do by choosing from :

1: Exit transmission without touching .resume files so the user can mount media etc.

2: Let transmission reset .resume files so torrents have to be verified or downloaded.

This is my quick suggestion, maybe there is better solution. But anyway I think this issue should be addressed, because current behaviour of transmission isn't very nice to user. Now I have to verify 1tb again :S But I don't blame anyone :) Keep up the good work.

Change History (9)

comment:1 Changed 12 years ago by jah

  • Milestone changed from 1.30 to None Set

comment:2 Changed 12 years ago by charles

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

This appears to be a duplicate of #476?

comment:3 Changed 11 years ago by Vegar

  • Resolution duplicate deleted
  • Status changed from closed to reopened
  • Type changed from Enhancement to Bug
  • Version changed from 1.21 to 1.83

This bug is not a duplicate of #476 and it is not fixed, so I'm reopening.

Today when I started transmission, I too as the OP hadn't mounted my external hdd where most of my torrents live. Transmission responded by stopping all the torrents and marking them for a recheck. This is where the bug is.

I believe the appropriate way to handle this situation is to, upon startup, pause the torrents whose data has disappeared and instead see if the data is still missing when they're unpaused.

Rechecking 150 GB of data over the USB bus is going to take hours.

comment:4 Changed 11 years ago by esper256

This is definitely a problem for me and I am running 1.92 on OSX. I have Transmission set to download to a local download folder for performance reasons, but on completion move them (depending on which group they are) to an external NAS drive mounted via AFP. I have OSX set to mount the AFP drives on start so that I don't forget to mount them before I start transmission, but even still when wireless network switches to wired or something like that I get disconnected and I forget about transmission.

Now I have GBs of transfers in the paused state 0 bytes of total size completed. The full data files still are on my drive. When I select a torrent and select verify local data, it does nothing. Not sure if that's a separate bug that I should file somewhere. But this is a huge pain and not the first time I've had to deal with it with a recent version of Transmission.

comment:5 Changed 11 years ago by livings124

#3052 is a duplicate of this.

comment:6 Changed 11 years ago by Waldorf

May I sugest the logic:

If the drive is/becomes unavailable:

  • flag the affected torrents with a temporary pause
  • do not allow user to start the torrent, unless the've changed the location (maybe)

If the dive becomes available:

  • leave the torrents as-is (paused)
    • allow user to start them manually
  • restart them as-if they were never paused on the next time T starts

Or

  • un-pause automatically, when the drive becomes available

The becomes (un)available logic would be luxury, and probably to big to implement for an edge case as this. Also, no-one should unplug is drive while it's in use, but still...

comment:7 Changed 11 years ago by Longinus00

This is all handled in #2955 and should probably supersede this.

comment:8 Changed 10 years ago by charles

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

Closing this ticket is a subset of #2955

comment:9 Changed 10 years ago by charles

Ticket #3855 has been closed as a duplicate of this ticket.

Note: See TracTickets for help on using tickets.