Opened 15 years ago

Last modified 11 years ago

#1127 assigned bug

ALL torrents become paused with no error

Reported by: Revolt Owned by:
Priority: critical Milestone: not applicable
Component: libtorrent Version: 1.3.3
Keywords: paused, checking, stuck, pause Cc: ian.greenleaf@gmail.com, xpertbg@mail.bg, deluge@bc90021.net, amatus, websdaleandrew@gmail.com

Description

Hey there.

Ever since upgrading to 1.2.0, I've been getting this strange behaviour where some torrents (usually just one) become paused after initializing deluge.

From what I could understand from the logs, all torrents are paused on exit and I guess they must be resumed on deluge opening. It seems that this one torrent sometimes stays Paused even though every other one goes into a queued or seeding state. Sometimes a bunch of other torrents exhibit this behaviour aswell.

The strange thing is that when I right-click it and click resume it does nothing. I have to pause it (and according to the log it seems to pause the torrent which may imply that it is just an interface bug?) and then resume it.

I'm using Arch Linux with the latest packages from core, community and extra. Deluge 1.2.0 under a Gnome 2.28 environment. Torrents are stored in a Ext3 filesystem, config and application on Ext4 filesystem.

Change History (36)

comment:1 by Ian Young, 15 years ago

Cc: ian.greenleaf@gmail.com added

I've been having a problem that sounds similar but not exactly the same. Mine too has been happening since 1.2.0, currently Deluge 1.2.2 and libtorrent 0.14.9.

For me, a sizeable number of torrents (roughly 100 out of a total of 500) do not start properly when I run deluge. The exact number seems to vary from day to day. These torrents are all listed as "Checking" for me. Resume does not work, but Pause-Resume does.

comment:2 by Revolt, 15 years ago

Yep that occasionally happens to me aswell but not very often. Recently the number of affected torrents seems to have increased and I usually find 30+ torrents in the described state after starting deluge.

comment:3 by xpertbg, 15 years ago

I'm also affected. I'm using Debian Sid and Deluge 1.2.3. When I start deluge usually around 30 from 150 torrents are shown in the wrong state.

comment:4 by xpertbg, 15 years ago

Cc: xpertbg@mail.bg added

comment:5 by Calum, 15 years ago

Milestone: 1.3.0

comment:6 by Calum, 15 years ago

Component: othercore

This has also been recently reported in the forums: http://forum.deluge-torrent.org/viewtopic.php?f=7&t=30815

comment:7 by Revolt, 15 years ago

Ever since the latest libtorrent-rasterbar update it seems this problem disappeared. Don't know if it's indeed related or if I removed all the torrents that triggered such event. Wondering what is happening to others?

comment:8 by Damien Churchill, 15 years ago

Status: newpending

Is this still valid?

comment:9 by skuppyJ, 15 years ago

It is. I still am having this issue with the latest version 1.2.3 for Windows 7 x64.

comment:10 by Damien Churchill, 15 years ago

Ah we'll need to get a Windows build out with libtorrent 0.15 to check on there. I should've directed that question to people running libtorrent 0.15.

comment:11 by skuppyJ, 15 years ago

Yeah, Windows has libtorrent 0.14.10.0, I'm sure you are well aware. Is it possible to force an upgrade to 0.15 on Windows? Or will the devs have to compile a new package..?

comment:12 by Damien Churchill, 15 years ago

You could try installing Python 2.6 and python-libtorrent separately and then copy across the files that libtorrent installed (probably in C:\Python26\Lib\site-packages\) over to Deluge's Deluge-Python folder.

comment:13 by skuppyJ, 15 years ago

Alright, I did it and now I'm running libtorrent 0.15 successfully. However, the problem still arises. It is a little better--I used to have twice as many paused state torrents before the upgrade. Now I only have 13 out of 134.

comment:14 by Damien Churchill, 15 years ago

Component: corelibtorrent

An improvement at least, I guess this is a libtorrent issue then.

comment:15 by Damien Churchill, 15 years ago

Milestone: 1.3.01.4.0

comment:16 by skuppyJ, 15 years ago

Well it seems after a restart, the problem disappeared. So I think the libtorrent upgrade actually worked. So far I have started the program on 4 or 5 separate occasions without the issue, so I can confidently say that the issue is fixed.

comment:17 by trac-robot, 15 years ago

Status: pendingclosed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:18 by jasker, 14 years ago

Status: closedreopened
Version: 1.2.01.3.1

This bug is still present in 1.3.1 under Windows (running Win7 x64).

in reply to:  18 comment:19 by skuppyJ, 14 years ago

Replying to jasker:

This bug is still present in 1.3.1 under Windows (running Win7 x64).

Yes, I was going to comment on this today. I have been having this issue again with Deluge 1.3.1 and the latest libtorrent 0.14.12.0 on Windows 7 x64.

comment:20 by skuppyJ, 14 years ago

Keywords: paused checking stuck added
Owner: set to skuppyJ
Status: reopenedaccepted

Still an issue. Very annoying. I can't seem to see any correlation with the two plugins I am using (AutoAdd, Blocklist, Label).

I have a copy of the shortcut to the executable in "C:\Users\Joseph\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" so it runs when the computer starts.

I will experiment with making it run as a service at bootup.

comment:21 by Calum, 14 years ago

Milestone: 1.4.0
Status: acceptedpending

Win32 1.3.2 release now uses lt 0.15.6

comment:22 by Calum, 12 years ago

Milestone: 1.3.x
Owner: skuppyJ removed
Status: pendingassigned

Bug also reported recently in #2111

The problem with this bug is that we need a reproducible method to test it and then determine if it is Deluge or libtorrent code.

comment:23 by bc90141, 12 years ago

Cc: deluge@bc90021.net added
Keywords: pause added
Priority: minormajor

I am having this issue. I recently changed from "regular" Ubuntu to Bodhi with a fresh install. I did not save or upgrade anything from my original Ubuntu and started from scratch with a full format of my drive for Bodhi.

I am using 1.3.5 with libtorrent 0.15.10.0.

All my torrents start in a Paused state. It's highly annoying. Nothing I do in the UI will ever make them unpause. I can force re-check, in which case it re-checks and then pauses. If I resume all, nothing happens. If I pause and resume all, nothing happens. If I pause each one and then resume each one ... nothing happens. If I right click on "Paused" under "States" and select "Resume All" ... you get the idea.

On initial install of Bodhi, I had this issue. I deleted all the configs in the deluge folder under the .config in my home directory, and was able to use Deluge without issue. However, once I closed it and reopened it, the problem returned. I can continue to do this but it is highly tedious to have to re-setup Deluge after every time I close it.

in reply to:  23 ; comment:24 by bc90141, 12 years ago

This is still occurring. I was forced to quit deluge (as I could no longer change any of the values that were in the window that comes up when clicking a .torrent) and consequently, right now - all my torrents are in a paused state. In order to get there I had to:

  • restart deluge
    • when I did this, all my torrents were gone!
    • I had to installed "deluged" and then connect to my local server (since when?) in order to get my torrents back
  • once my torrents were back, I attempted to resume them all
    • group resume does not work
    • individual resume does not work

So now I can't even see my own torrents unless I connect to the deluged on my localhost (that's a first (!)) and even when I do the torrents are all paused. I'm sure the only way I'm going to be able to do anything about this is to completely reset Deluge AGAIN.

Can anyone tell me where the state is set so I can even change it manually? I don't care if I have to edit files - this makes deluge essentially unusable at the moment.

in reply to:  24 comment:25 by bc90141, 12 years ago

Version: 1.3.11.3.5

Lest people think I am only complaining, here is the terminal output from when I run deluge at the command line:

Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 413, in fireEvent
    DeferredList(beforeResults).addCallback(self._continueFiring)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 298, in addCallback
    callbackKeywords=kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 287, in addCallbacks
    self._runCallbacks()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 545, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 426, in _continueFiring
    callable(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/gtkui.py", line 336, in _on_reactor_start
    self.__start_non_classic()
  File "/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/gtkui.py", line 376, in __start_non_classic
    reactor.simulate()
exceptions.AttributeError: 'Gtk2Reactor' object has no attribute 'simulate'
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/init.py", line 48, in enable
    self.plugin.enable()
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/Blocklist-1.2.egg/blocklist/core.py", line 116, in enable
    self.update_timer.start(self.config["check_after_days"] * 24 * 60 * 60, update_now)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/task.py", line 163, in start
    self()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/task.py", line 208, in __call__
    d = defer.maybeDeferred(self.f, *self.a, **self.kw)
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 134, in maybeDeferred
    result = f(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/Blocklist-1.2.egg/blocklist/core.py", line 155, in check_import
    d = self.import_list(self.config["url"])
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/Blocklist-1.2.egg/blocklist/core.py", line 343, in import_list
    self.auto_detect(blocklist)
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/Blocklist-1.2.egg/blocklist/core.py", line 417, in auto_detect
    self.config["list_compression"] = detect_compression(blocklist)
  File "/usr/lib/python2.7/dist-packages/deluge/plugins/Blocklist-1.2.egg/blocklist/detect.py", line 61, in detect_compression
    f = open(filename, "rb")
exceptions.TypeError: coercing to Unicode: need string or buffer, NoneType found
/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/torrentview.py:507: GtkWarning: IA__gtk_tree_model_filter_convert_iter_to_child_iter: assertion `filter_iter->stamp == filter->priv->stamp' failed
  child_row = self.treeview.get_model().get_model().convert_iter_to_child_iter(child_row)

comment:26 by Calum, 12 years ago

I'm afraid all those error are irrelevant to this issue.

exceptions.AttributeError: 'Gtk2Reactor' object has no attribute 'simulate'

This first error has already been reported: #2148

exceptions.TypeError: coercing to Unicode: need string or buffer, NoneType found

This second error is in the blocklist plugin, have you supplied a blocklist location? A new ticket should be created so this can be discussed and fixed separately.

/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/torrentview.py:507: GtkWarning: IAgtk_tree_model_filter_convert_iter_to_child_iter: assertion `filter_iter->stamp == filter->priv->stamp' failed

child_row = self.treeview.get_model().get_model().convert_iter_to_child_iter(child_row)

This third one is simply a gtk warning that can be ignored.

in reply to:  26 comment:27 by bc90141, 12 years ago

Replying to Cas:

I'm afraid all those error are irrelevant to this issue.

exceptions.AttributeError: 'Gtk2Reactor' object has no attribute 'simulate'

This first error has already been reported: #2148

exceptions.TypeError: coercing to Unicode: need string or buffer, NoneType found

This second error is in the blocklist plugin, have you supplied a blocklist location? A new ticket should be created so this can be discussed and fixed separately.

/usr/lib/python2.7/dist-packages/deluge/ui/gtkui/torrentview.py:507: GtkWarning: IAgtk_tree_model_filter_convert_iter_to_child_iter: assertion `filter_iter->stamp == filter->priv->stamp' failed

child_row = self.treeview.get_model().get_model().convert_iter_to_child_iter(child_row)

This third one is simply a gtk warning that can be ignored.

I don't know that I supplied a blocklist location. I'll check that.

With respect to the rest, to be honest, I figured it wouldn't be much help, but I don't really have anything else to go on. What can I run to help diagnose this issue? Where is the state for the torrents stored? Is that in the deluge client or libtorrent? Can I run it in a debug mode? Is there some kind of log I can provide? I'd really like to help figure this issue out, but don't know where to start. :-/

comment:28 by bc90141, 12 years ago

Component: libtorrentgtkui

Unfortunately, this bug has now driven me past the point of continuing to use Deluge. I had had no problems with it until recently, but they continue to crop up. Now instead of having paused un-resumable torrents, I now have no torrents, even though there are fifty listed in the "state" directory. I don't know what I suddenly have had to start connecting to a daemon when I've never had to before, either. This program was so simple and easy to use, and had a really powerful set of features - now it's a constant hunt to try and find the torrents which are right under its nose which it can't access anyway because it either can't connect to the daemon and think it can or the daemon doesn't know what to do with the connection. It's just a huge mess that makes things really difficult, and so I have uninstalled it.

comment:29 by Calum, 12 years ago

Component: gtkuilibtorrent

I ran across this qbittorrent bug that seems to be very similar to this: https://bugs.launchpad.net/qbittorrent/+bug/754742

There are some suggestions of removing bad trackers may help so that is worth looking at.

Even though a few other bugs may crop up it is worth testing with latest 0.16 libtorrent.

comment:30 by amatus, 12 years ago

Cc: amatus added

Deluge 1.3.5 + libtorrent 0.16.3 (svn) also affected by this bug. I would add that downloading torrents continues, even though they are marked as paused.

comment:31 by amatus, 12 years ago

I managed to find a way to bring back a status of all torrents. After starting the deluge: 1. select all torrents. 2. right click -> options tab -> select "Auto Managed" on. I think that this problem in a core.

comment:32 by nogare, 12 years ago

I encounter this issue as well when I upgrade to libtorrent .16, I can confirm it exists.

comment:33 by Ian Young, 12 years ago

I tried @amatus' solution and while it worked temporarily, the problem returned after restarting deluge.

By the way, I can also temporarily resolve the problem by simply pausing and then resuming the affected torrents (it's important to hit "pause" first, even though they already appear as paused).

comment:34 by Calum, 12 years ago

Milestone: 1.3.xnot applicable

comment:35 by gouchout, 12 years ago

Cc: websdaleandrew@gmail.com added
Priority: majorcritical
Summary: Some torrents become paused with no errorALL torrents become paused with no error
Version: 1.3.51.3.3

This has just started happening to me.I'm using Debian Wheezy with Deluge 1.3.3 libtorrent-0.15.10. I've used Deluge for ages. Unless this is fixed soon I'll have to stop using Deluge at least until the bug is fixed. I'm sure many other Debian Wheezy users will feel the same. Please can someone have a look at this as its obviously broken.

comment:36 by jb0nez, 11 years ago

I am using Deluge 1.3.6 on Win 7 x64 and I just had this bug happen to me, but with just one torrent. A torrent was stuck in paused state, the only thing that could get it out was pause then resume, after which point it was fine.

When I look at the seeding time it was 14 minutes though deluge had been open for 15 hours. I was sequentially downloading a number of small torrents at the time but my number to seed was set low and I think when I hit my upload number a bunch of other torrents were put into Queued state but this one and another were put into Paused state. Maybe this has something to do with it. (The other one wouldn't even start with Pause-resume, I had to delete the torrent and download it again to get it to start seeding.)

Note: See TracTickets for help on using tickets.