Opened 15 years ago

Closed 14 years ago

Last modified 7 years ago

#1174 closed bug

Incorrect reporting of Download Progress

Reported by: Calum Owned by: andar
Priority: major Milestone: 2.x
Component: Core Version: 1.2.1
Keywords: Cc:

Description

Twice now I have had problems with torrents that have been downloading slowly reporting different progress percentage to the actual amount on data downloaded for the file.

The issue with the latest torrent, 1.5Gb total size: Shows in status, Downloaded: 500Mb (300Mb) but only 9% progress. I forced a recheck at which point it reported progress to be 0%. To fix this I removed the torrent leaving the data, added it again at which point Deluge checked it and reported the more accurate 27% progress and continued to download.

Forums posts about this issue: mintz Cas

Change History (11)

comment:1 by Calum, 15 years ago

Milestone: 1.3.0

I have not seen this for a while but turbozinc post on my thread in the forum that he was experiencing the same with 1.2.2. It seems to affects torrents over 1GB in size

comment:2 by Damien Churchill, 15 years ago

Owner: set to andar
Status: newassigned

comment:3 by maxadamo, 15 years ago

Am I right if I say that this happens if you stop deluge-daemon prior to pause a torrent? I wouldn't be wrong, but I noticed this issue when I reboot the machine and the daemon was stopped during poweroff operations. Again, I don't want to confuse things, as I am sure that this happens with torrentflux, but I think I have seen the same with deluge. Hope it helps, and I am not adding much more confusion.

comment:4 by andar, 15 years ago

What filesystem is in use for these downloads?

comment:5 by maxadamo, 15 years ago

Ok. I used xfs and now ext4 and most probably I was wrong (I said that I was unsure). Linux uses sparse files and this kind of problem, may happen only in windows. Right?

comment:6 by andar, 15 years ago

Status: assignedpending

Has this been confirmed to still be an issue with the latest master?

comment:7 by maxadamo, 15 years ago

if this issue comes from version 1.2.1, and we come accross version 1.2.3, it won't be a stopper (or a milestone) for version 1.3.0 (as it wasn't a stopper for 1.2.3). Furthermore, if you are knocking the ticket issuer, and you're not getting any answer what can we do? My two cent: forget it (for now) and give 1.3.0 packaged to the masses _ cheers. Massimiliano

comment:8 by John Garland, 14 years ago

Milestone: 1.3.01.4.0

comment:9 by mintz, 14 years ago

This is not a Windows issue. I am experiencing this problem with 1.23 on a seedbox with simfs. The server is runing Ubuntu 8.04 so I can't use the up-to-date PPA binaries, so I compiled this from source. I was also getting it with 1.21. I haven't compiled 1.30 yet so I don't know if its still a current problem.

comment:10 by trac-robot, 14 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:11 by Calum, 7 years ago

Milestone: 2.0.x2.x

Milestone renamed

Note: See TracTickets for help on using tickets.