Custom Query (2447 matches)
Results (499 - 501 of 2447)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3448 | Duplicate | Incorrect statistics in Status page | ||
| Description |
Statistics in the status page are incorrect. Speed and downloaded size are mixed for both upload and download. See the image below for more details.
Versions: Client: 2.0.3 Server: 2.0.3 libtorrent: 1.1.13.0 |
|||
| #3519 | Duplicate | /tmp filled with millions of deluge_ticon.xxxxx files | ||
| Description |
My /tmp directory was filled with millions of deluge_ticon.xxxxx files, causing the Server to malfunction. My guess is that it is the same bug as: https://dev.deluge-torrent.org/ticket/3167#no4 But that was marked as GTK-UI, but it happened to me with the webUI. So I opened a new ticket. Deluge 2.0.4 |
|||
| #42 | WontFix | Writes and Reads reduction. | ||
| Description |
I've noticed that Deluge 0.5.8.4 keeps flushing the data back to the drive almost immidiately after it receives it. It also seems to read data for uploading as it's needed. With just one torrent going 100KB/s down and 50KB/s up my HDD LED keeps flashing like crazy. This is very taxing for hard drives. Please make an option available to have the data flushed less frequently (like a slider with some reasonable values and a reasonable default value, say 2MB). This would reduce writes. Also, some sort of intelligent and more RAM-heavy (hey, RAM is cheap and it could be optional) uploading mechanism would be in order. Like buffering more data at once, I'm not sure how the protocol works, but parts that have most demand could be pre-emptively cached or/and if there's some sort of a queue, parse who needs what in advance and cache this data in bigger chunks in preperation before sending it. This would reduce reads. |
|||
