Opened 10 years ago

Closed 10 years ago

#2496 closed bug (Fixed)

Torrents stuck in Queued Torrents

Reported by: awknaust Owned by:
Priority: minor Milestone: 1.3.8
Component: GTK UI Version: 1.3.7
Keywords: queued torrent, classic mode Cc:

Description

I have had this issue on debian with 1.36-dev and have replicated it on a Ubuntu 14.04 VM with 1.37-dev

Description of problem In classic mode, using a local or non-local daemon you can get into a situation when adding torrents they are put into the "Queued Torrents" dialog, but cannot be added from there, because the Add button is disabled. Deluge also fails to add them automatically. Also if you press the 'Clear' button the torrent will disappear from the dialog, but in the status bar "1 Torrent Queued" will remain.

http://imgur.com/yp4K9GB.png

Replication You will need access to 2 torrents (I used http://cdimage.debian.org/debian-cd/7.6.0/amd64/bt-cd/)

With a fresh copy of 1.37-dev perform the following actions

  1. Start deluge, disable classic mode via preferences, close deluge
  1. Start deluge, in connection dialog check 'start local if needed', 'connect on startup', 'don't show this dialog', close deluge
  1. With deluge-gtk closed, try to add a torrent via clinking a link, or simply "deluge-gtk torrentname.torrent". Check 'automatically add torrents on connect', and then 'Add' to add the torrent. It should begin downloading, close deluge
  1. With deluge-gtk closed, try to add (another) torrent as in 3. This should produce the error condition: the torrent will not be automatically added, and if you bring up the "Torrent Queued" dialog, Adding will be disabled.

Attachments (1)

debug.log (19.0 KB) - added by awknaust 10 years ago.
Command line input/errors, and debug-level log

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by awknaust

Command line input/errors, and debug-level log

comment:1 Changed 10 years ago by awknaust

I think I've traced this to a bug in addtorrentdialog.py. It relies on a deferred object to get the config values and set the core_config dictionary. This deferred is called either from start() or show(). However when you add a torrent it eventually goes to add_from_files, which calls set_default_options, assuming core_config is already loaded.

Unfortunately when this assumption fails, it throws an error, and doesn't open the add torrent dialog. The queued torrents dialog assumes adding will always be successful, so it clears its own queue.

This problem is probably also present with add_from_magnets, add_from_url

I'd like to write a patch, but I'm just a beginner with deluge/twisted. Should you somehow block on the core config, or just call update_core_config again in add_from_files and split the rest of it into a callback?

Last edited 10 years ago by awknaust (previous) (diff)

comment:2 Changed 10 years ago by Cas

I guessed that might be the issue.

What version is the remote daemon?

Last edited 10 years ago by Cas (previous) (diff)

comment:3 Changed 10 years ago by Cas

  • Milestone changed from Future to 1.3.8

comment:4 Changed 10 years ago by Cas

Ignore my previous question, I didn't read your report properly :)

I have actually been trying to replicate the 'download_location' issue for a long time so your detailed steps on how to replicate are really useful, thanks.

comment:5 Changed 10 years ago by awknaust

I've managed to do it with a freshly installed 1.37-dev (and probably 1.37-dev daemon). I originally noticed it with 1.36 daemon

comment:6 Changed 10 years ago by Cas

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

Fixed in 1.3-stable: [33339b1dc6]

Note: See TracTickets for help on using tickets.