1.0.0_RC9 (0.9.09) Released

[Nanobot]

Okay, I'm going to be frank here: I'm starting to get really pissed off at the RCs. Deluge used to be a really good client, but ever since the RCs it has had one disastrous bug after another.

I just rebooted my system, opened up Deluge, and found that all of my downloading torrents were gone. Everything that was seeding is still there, plus a ton of torrents that I had previously removed from my list. But everything that was in progress of downloading had vanished. I couldn't find any trace of the .torrent files either.

There was, however, one torrent that was downloading when I opened Deluge, and it was a torrent which was previously complete and seeding! Somehow now it only has about 50% progress.

For the other torrents, I had to go on the Web and hunt down the original torrent files and re-add them. Once I did, and Deluge did the re-check, I found that I had at least a few days' worth of data gone on each torrent. One of the torrents (a batch of files) previously had one file at 99% and the rest at about 60%, and now all of the files are at about 25%. A separate single-file torrent went from about 90% to 2%.

And just as I was typing this in my Firefox window, Deluge silently crashed.

With these kinds of major data loss bugs, plus the file progress bugs and UI regressions, I think it's ludicrous that these versions are promoted on the front page as "release candidates", or even anything close to beta. I'm "downgrading" to the 0.5 series so that I can have a usable bittorrent client again.

This is very strange. I have never experienced any of the issues you describe and there has never been any bug reports indicating the same. Perhaps instead of bitching you could help track down the bugs by filing tickets with log files and steps to reproduce.

This bug sure looks like it's related: http://dev.deluge-torrent.org/ticket/295

[kin]

For some reason limiting the upload bandwidth also completely kills the download speed for me. If I for example put on an upstream limit of 100KB/s, my downstream immediately and reproducably falls from 3,5MB/s to 300KB/s. This seems to be proportional, because a limit fo 20KB/s make almost everything grind to a halt.
I'm using RC4 on the latest kernel (2.6.26) on Gentoo and I'm portforwarding everything to a single port I set in Deluge.

Have you set it that high successfully before this release?
It sounds to me like you maxed out the upload therefore basically preventing downloading from occurring. Check what your ISP is offering you for upload speed, and maybe check to see if that is what you are getting when you are not using the connection for anything else.

You have that backwards. I am capable of 5MB/s download ~2MB/s upload and have had absolutely no problem achieving either at the same time until now, even when limiting either.
The problem is that when I limit the upload bandwidth in Deluge to less than I am capable of (say, 20KB/s), my upstream also immediately falls to a fraction of what it should be (about 3 times my upload limit?), and rises again when I take off the limit. It is not a problem of the bandwidth my ISP provides me with. And no, I haven't had this problem with previous Deluge releases.

[mickstephenson]

For some reason limiting the upload bandwidth also completely kills the download speed for me. If I for example put on an upstream limit of 100KB/s, my downstream immediately and reproducably falls from 3,5MB/s to 300KB/s. This seems to be proportional, because a limit fo 20KB/s make almost everything grind to a halt.
I'm using RC4 on the latest kernel (2.6.26) on Gentoo and I'm portforwarding everything to a single port I set in Deluge.

Have you set it that high successfully before this release?
It sounds to me like you maxed out the upload therefore basically preventing downloading from occurring. Check what your ISP is offering you for upload speed, and maybe check to see if that is what you are getting when you are not using the connection for anything else.

You have that backwards. I am capable of 5MB/s download ~2MB/s upload and have had absolutely no problem achieving either at the same time until now, even when limiting either.
The problem is that when I limit the upload bandwidth in Deluge to less than I am capable of (say, 20KB/s), my upstream also immediately falls to a fraction of what it should be (about 3 times my upload limit?), and rises again when I take off the limit. It is not a problem of the bandwidth my ISP provides me with. And no, I haven't had this problem with previous Deluge releases.

I second Kin's take on this, although my experience is purely anecdotal, and could be coincidental but I have noticed a somewhat throttled downspeed when I lower my upspeed

[good1]

This is possibly the wrong thread for this...but...All our bitching finally paid off:

Peers Progress was just implemented in trunk and should be in Deluge 1.1.0 YAY!!!

Amen

Contrary to some of the opinions here, I think that the new UI is a great improvement. The default add torrent dialog is a great improvement over previous versions. It's very easy to select a download location and pieces of files if you want and the fact that it remembers the last chosen location also is a feature that I have been missing. I think having the last 5 locations would be even better as I have 4 or five regular places that I drop files. Perhaps a list of favourites?

There are a few bugs, but that is what Beat and RCs are all about.

Keep up the great work guys.

Mark

and Amen again. For the people who are losing data, RCs are WIP(work in progress) material. It's always a good idea to backup the partial downloads before using RCs, or at least only use the torrents that you're willing to have tested on(ones that are not a big deal to lose). I still use the 5x deluge, but have the RC4 installed to another directory.

Also, in RC4 for windows (may be it's been around in previous releases) but after configuring the options a certain way, RC4 crashes on start, and the only way to fix it is to just delete the config files. I'm trying to find a way to reproduce the bug, but has anyone else had this happen, where RC crashes on start?

[Major_Kong]

I'm getting a strange error. Deluge gives me a error saying it can't find the downloaded files/directories of a torrent after restart. This only seems to happen when using compact allocation.

[devil81]

I have to agree with the poster good1 that this RC is far less stable than previous versions and will hang on a particular outline (screen title, white box) for quite a long time before loading, my record so far is 15 mins, or it will crash completely taking my system down with it and then the only way to bring it back, is to go into Task Manager and kill off all deluge and python processes and reloading it. In some cases, it also necessary as stated by good1, to go into the Vista AppData folder and completely remove the deluge config, which can get very irritating having to reconfig delug.

I have also noticed that the CPU spikes are more noticeable and frequent than in previous builds and also that at times the blocklist gui will hang or freeze when downloading or importing a blocklist.

[Drako60]

I can confirm that download speeds are being limited in RC4, i downgraded to RC3 and my speeds went from 20-50K/s to 50-100+K/s, I don't know what would be causing this though.

I can also confirm that atleast until RC3 that files were not resuming properly and loosing data, dropping anywhere from 90% complete down to as little as 1.2% complete, I don't now if this is in the state file for the torrent, or in the write out of cached data segment of the code. I have found this bug only presents itself after a close of Deluge or a force recheck, pausing a torrent does not cause this

I believe that the CPU Spike bug is also in the write to disk segment of the code, or in the Peer connect code, as I've found that if I pause the torrents the CPU Spike stops, I've also had the CPU Spike bug cause deluge to stop responding, cause massive system lag, caused Gnome to stop responding to the point of having to do ctrl+alt+backspace, and even had it hard lock the system to the point of a hard restart, the hard lock was durring SVN 0.6 and was preluded to by deluge not responding and gnome stopped responding shortly after.
I have not noticed any unusual disk activity durring the CPU spike

I can also now confirm that the CPU Spike bug is in the saving of the state file.
[DEBUG ] 16:23:12 torrentmanager:543 Saving torrent state file.
Which ran for a full 2 minutes before it stopped

I'm running Debian Lenny, AMD64 x2 2.60, with 2GBs ram.

Also Ander the Resume bug was reported on page 10 or 11 of this thread, by myself and at least one other, as i had assumed this was for dicussion and notification of bugs within the RCs.

[devil81]

I dont know what has happened during the development of this RC but the download speeds have significantly dropped from an average of 400kb\s + in the previous RC to little more than 50kb\s when downloading 3 torrents. I have also tried the same torrents in a different client(who shall remain nameless) and get over 300kb\s and all torrents started and resume much faster than in the aforementioned client.

In fact some torrents will not even to begin to download or connect to peers in the current RC although they do so almost instantly in other clients.

Apologies for the distinctly untechnicality outline, but its late and my programming expertise, in Python is limited to say the least.

[traxen]

Okay, I'm going to be frank here: I'm starting to get really pissed off at the RCs. Deluge used to be a really good client, but ever since the RCs it has had one disastrous bug after another.

I just rebooted my system, opened up Deluge, and found that all of my downloading torrents were gone. Everything that was seeding is still there, plus a ton of torrents that I had previously removed from my list. But everything that was in progress of downloading had vanished. I couldn't find any trace of the .torrent files either.

There was, however, one torrent that was downloading when I opened Deluge, and it was a torrent which was previously complete and seeding! Somehow now it only has about 50% progress.

For the other torrents, I had to go on the Web and hunt down the original torrent files and re-add them. Once I did, and Deluge did the re-check, I found that I had at least a few days' worth of data gone on each torrent. One of the torrents (a batch of files) previously had one file at 99% and the rest at about 60%, and now all of the files are at about 25%. A separate single-file torrent went from about 90% to 2%.

And just as I was typing this in my Firefox window, Deluge silently crashed.

With these kinds of major data loss bugs, plus the file progress bugs and UI regressions, I think it's ludicrous that these versions are promoted on the front page as "release candidates", or even anything close to beta. I'm "downgrading" to the 0.5 series so that I can have a usable bittorrent client again.

I can confirm what he said. I use Ubuntu Hardy and have experienced these data drops. I've gone back to using 0.5.9.3 now since that was the last non destructive client working for me. So I feel a bit related to his frustration due to losing huge amounts of data in one sudden go.

Wish I could provide a log for you but since I only have one PC and a full queue I'm not setting my foot into the lions den again until I hear that something has settled

P.S I do like the look of the new client so good luck fending off the lions

[devil81]

I have just noticed something concerning the Windows port of the deluge client. When you quit the client, only the deluge.exe * 32 and one of the python.exe * 32 processes as they appear in the Task Manager, are terminated. The deluged.exe * 32 and the other python.exe * 32 process, still reside in memory and then have to be manually terminated.

Surely all processes created and used by the client should be killed off when the main application is exited?