Deluge Forum

Deluge 2.0.5 running on linux. libtorrent 1.2.14.0

I have couple of seeding torrents that show as completed on webui & confirmed by private tracker, but deluge-console disagrees: Pay attention to the Size row - it implies .1 G is yet to be downloaded.
Is it an issue with Deluge or my environment? Have seen this w/ 2 torrents so far. Never noticed this discrepancy with deluge v1.

No, when 'total_done == total_size' , then both shown separated with '/' - the former is the size whereas the later includes possible padding files to align files on piece-boundaries. This was same for v1.3.x console UI btw, except always shown.

Sorry think I'm not following. Are you claiming it's correct output from the console, given the torrent actually has completed downloading & is now seeding? To me it appears that it thinks 0.1G remains to be downloaded (50.8 < 50.9), but that's not really the case. Note the whole torrent was downloaded as well, not a subset of its files.

Yes

The torrent(content) is 50.8 GiB and 50.8 GiB downloaded - then additionally just shown for completeness that the torrent actually is 50.9 big in size when everything included i.e padding files. The torrent is showing as seeding('State: Seeding' / 'ETA: -'). It's showing: 'Size: "size of torrent"/"same but included padding"''(later only shown if different from former, space-saving/redundancy considerations presumably).

Huh, interesting. So torrents often contain padding data? Is it something on the protocol level, or what torrent uploaders themselves need to explicitly create/define?

Also, does this also mean there's no way to know how much space a torrent will take on a drive once it's completed, based on console output?
For context, I have a shell script that periodically queries console output and checks how much data is left to be downloaded. That way it knows how much disk space will all the torrents take up once completed.

Honestly don't know anything about it, and just checked deluge source-code and libtorrent API-docs to answer your question

From quick reading, it was an unofficial addition by bitcommet many years ago and later implemented in most other clients for sometimes different reasons e.g performance, better deselecting files etc.

My understanding is that it doesn't affect the size on disk of downloaded data, so should be alright your usecase, unless I'm misunderstanding. Also, as said, deluge1 console-UI did same, with two numbers for filesize, one real and one padded, and deluge2 only shows both when there's a diff(so only one number when no pad-files or files included already aligned to filesystem-bounderies).

Yes I think the uploader can define padding or not when generating g torrent, atleast there's functions in libtorrent API for it.

Just checked the files - there is a .pad/ directory 69.5MiB in size listed, so that confirms your theory.
So guess it settles this.

mhertz wrote: ↑Tue Jan 18, 2022 3:33 pmdeluge2 only shows both when there's a diff

Think you're slightly wrong here. Those two values (separated by a slash) isn't designating padded & un-padded values per se. You'll see 2 values also for legit downloading torrents; eg 50.1 GiB/70.1 GiB for an unpadded torrent means exactly 20 GiB still remains to be downloaded. Which is exactly my problem - based on Size row of deluge-console you can't really say how much data is yet to be downloaded. You'll have to additionally check the State row and make sure it's... "Seeding"?

Ahh, of-course you're right! - Sorry for wrong info and thank's for correction I just initially stopped checking the code after seeing the formating of 'size' line for seeding torrents. Didn't think about other states, stupidly.

Anyway, I suppose you could just filter for 'downloading' state only, for deluge-console's 'info' command I mean('-s' switch), but you probably already found has a bug making this impossible unfortunetly, though thankfully jbrid shared his propossed bug-fix around a year ago here, and I reported it, together with jbrid's solution. Otherwise yes, you'd have to add that extra logic to your scripting, as you pointed out.

Cool, thanks for looking into it as always.