Custom Query (2449 matches)


Show under each result:

Results (103 - 105 of 2449)

Ticket Resolution Summary Owner Reporter
#2045 Fixed UnicodeDecodeError for non-english named torrents (non en_US locale) Cas angry_vincent
info "Torrent Name"
'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/deluge/ui/console/", line 328, in do_command
    ret = self._commands[cmd].handle(*args, **options.__dict__)
  File "/usr/lib64/python2.7/site-packages/deluge/ui/console/commands/", line 130, in handle
  File "/usr/lib64/python2.7/site-packages/deluge/ui/console/", line 445, in match_torrent
    if tid.startswith(string) or name.startswith(string):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)

#2895 Fixed Daemon deadlocks on start-up/shutdown when using SSL trackers Animazing

Hi guys,

I have been trying to diagnose a problem happening over multiple Deluge and Libtorrent versions but I'm getting stuck and could use some pointers.

Since a week or so I have multiple Deluge instances locking up on multiple servers (all Ubuntu 14.04) when the clients are using SSL trackers. It will either get stuck during boot or during shutdown. I could only replicate it with more then 3 torrents, with just one or two nothing happened.

sed-ing all the https announce urls to http solves it.

This happens on Deluge 1.3.6 to 1.3.13 and libtorrent 0.16.x to 1.0.1. Since it happens on almost every combination possible I'm assuming there is something else on my servers interfering with the normal operation. I did notice an unattended upgrade for openssl but even when downgrading the problems kept happening.

Any hints as to how to debug this further would be greatly welcomed.

#295 WorksForMe Deluge not downloading complete blocks markybob aninhumer@…

This is the issue explained here:

Deluge is not completing the blocks during downloading any torrents, leading to much smaller file completion reports than overall completion, difficulty in seeding, and potential huge data loss on any recheck. (Which happened to me once)

Probably the same bug also means files marked "Highest" are not much faster to download than others, or at least take much longer than they did before.

Possibly this is a new/'improved' parts selecting algorithm?

(I have submitted this under "critical", as I believe it is a critical issue, however I am unfamiliar with this system, so please change it if you do not agree.)

Note: See TracQuery for help on using queries.