Opened 10 years ago

Closed 9 years ago

#4874 closed Bug (fixed)

Deleting multiple torrents from the WebUI fails

Reported by: diamondsw Owned by: wlisac
Priority: High Milestone: 2.70
Component: Mac Client Version: 2.50
Severity: Normal Keywords:
Cc: bed@…, will@…

Description

Starting with Transmission 2.5.0, deleting multiple torrents (such as when cleaning out completed and inactive torrents) via the web UI fails. Multiple torrents can be selected, but when the delete button is clicked only one is removed (seemingly at random). The remaining torrents are permanently displayed in the Web UI and can no longer be acted upon or deleted. They disappear from the application GUI, although the bandwidth statistics indicate that they are indeed still alive and seeding. If I recall correctly, the incomplete files (if the torrent is still downloading) are not removed as expected.

This persists until Transmission is quit and relaunched, at which time the torrents are gone from all views, but the incomplete files remain (as I recall).

Attachments (3)

Transmission_2012-09-03-123825_Wills-Mac-Pro.crash (44.8 KB) - added by wlisac 9 years ago.
Crash report after deleting multiple files via RPC then adding multiple files in quick succession.
Transmission_2012-09-03-132723_Wills-Mac-Pro.crash (46.0 KB) - added by wlisac 9 years ago.
Crash report after deleting multiple files via RPC then adding adding additional files. This is with the latest nightly build.
Controller.m (185.5 KB) - added by wlisac 9 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 9 years ago by profplump

I can regularly reproduce this zombie-transfer issue -- shift-click to delete multiple transfers via the web interface, they are all removed from the thick GUI but only one is removed from the web UI. Future attempts to delete the now-zombie transfers via the web UI are ignored. Restarting Transmission resolves the issue.

I can also reproduce this issue with a custom client that uses the web API, where two torrents are deleted in separate requests (but in the same session).

I haven't directly measured the maximum duration between requests where this error is trigged, but the upper bound is a single-digit number of seconds, with longer delays between delete requests avoiding the issue entirely. So a workaround is to individually delete transfers (though that's much more plausible in scripting than in manual use).

comment:2 Changed 9 years ago by jeromeof

I can also regularly reproduce this problem and obviously it appears on all clients using both the Web UI and the API (so things like Transmission Remote GUI also has this zombie torrents stuck in the list issue).

comment:4 Changed 9 years ago by bed

  • Cc bed@… added

I also can replicate this issue without fail (transmission running on OSX 10.7) when trying to delete multiple torrents via the web interface - all exactly as previously described.

comment:5 Changed 9 years ago by cfpp2p

If I recall correctly, the incomplete files (if the torrent is still downloading) are not removed as expected.

Now , if I'm reading this correctly, some of the torrents are still downloading. Then #1753 would apply and torrents must be paused before being deleted. On MAC there is no pre-allocation and the pause must zero out bytes first, sometimes requiring many minutes to do so and often appearing as a lock. During this zeroing out transmission wouldn't be able to delete then next torrent until the pause (zero out, then delete ==> long wait ) of the previous torrent deletion. The web gui might not be updated correctly during this long tedious wait.

Have you tried waiting a long time ( allowing the zeroing out to finish ) to see if deleting finishes properly.

I'm trying to gain an understanding of the situation at hand.

comment:6 Changed 9 years ago by profplump

I do not think #1753 is related.

I can reproduce this problem even when deleting only completed, non-seeding torrents. When I've left the system unattended I've seen the state persist for more than 24 hours.

Just now I tested on a pair of torrents that were both under 200 MB data size and in the completed-paused state; the first one was removed from disk and both UIs within the normal update window (a few seconds). The second disappeared from the main GUI but remained on-disk and in the WebUI. Waiting for 10 minutes produced no change. During the delay I could pause and resume the zombie torrent, but additional attempts to delete it had no effect.

comment:7 Changed 9 years ago by diamondsw

I've trained myself to (slowly) delete only one torrent at a time (or VNC to the server to use the GUI), so I haven't run into it for a while. However, profplump's description sounds spot-on to what I recall. Typically I was removing torrents that were complete, and they would persist indefinitely - even for days.

comment:8 Changed 9 years ago by wlisac

  • Cc will@… added

comment:9 Changed 9 years ago by wlisac

  • Priority changed from Normal to High

I am having the same issue. Active downloads continue to download for me after multiple delete. Transmission on the Mac often crashes when it enters this inconsistent state.

comment:10 Changed 9 years ago by livings124

Can you supply a crash log?

Changed 9 years ago by wlisac

Crash report after deleting multiple files via RPC then adding multiple files in quick succession.

comment:11 Changed 9 years ago by livings124

Can you try a nightly build from https://build.transmissionbt.com/job/trunk-mac/ and attach a crash log. Thanks!

comment:12 Changed 9 years ago by wlisac

I downloaded the latest nightly build but I'm not sure how to attach a crash log.

comment:13 Changed 9 years ago by livings124

You already attached a crash log before. Just do the same thing with a crash log if/when the nightly crashes.

Changed 9 years ago by wlisac

Crash report after deleting multiple files via RPC then adding adding additional files. This is with the latest nightly build.

comment:14 Changed 9 years ago by livings124

  • Component changed from Web Client to libtransmission
  • Owner set to jordan

comment:15 Changed 9 years ago by wlisac

@livings124 did the crash reports help with tracking down the issue?

comment:16 Changed 9 years ago by livings124

I believe it's an issue in the libtransmission engine, so jordan will have to weigh in .

Changed 9 years ago by wlisac

comment:17 Changed 9 years ago by wlisac

I finally had a chance to look at this tonight and I believe I fixed the problem. The Mac OS X Controller.m had an animation bug that was messing up the completion handler responsible for deleting the torrents.

Specifically, the RPC Callback tells the controller to delete torrents one at a time which calls the following method in quick succession:

  • (void) confirmRemoveTorrents: (NSArray *) torrents deleteData: (BOOL) deleteData

Long story short, we need to put [NSAnimationContext beginGrouping]; before we set the completion handler for the current context. If we don't then the completion handler is replaced each pass through the above method and only the last one gets called.

This leaves all the torrents still running except for the last one, despite removing them from the table view.

I have attached the .m file with the fix.

Thanks, Will Lisac

comment:18 Changed 9 years ago by wlisac

  • Component changed from libtransmission to Mac Client
  • Owner changed from jordan to wlisac

comment:19 Changed 9 years ago by livings124

  • Milestone changed from None Set to 2.70
  • Resolution set to fixed
  • Status changed from new to closed

Good catch! r13490

Last edited 9 years ago by livings124 (previous) (diff)
Note: See TracTickets for help on using tickets.