I have the latest 2.1.1 version. Attached is a screenshot that shows that out of 100 various parts skipped my Deluge downloads only 1 part that was ticked in and barely touches the other, but somehow downloads 20 other parts that were supposed to be skipped
I hope such a behavior could be fixed in the coming versions
For me it happens much less when having prioritize first/last pieces disabled, or with libtorrent 1.2.x, but not fool-proof workaround though. I will make a ticket later probably, but just is hard when no reproducal scenario that shows the issue(always I mean, took me a bunch tests to notice even), but atleast 3 people could trigger this, just lately. You can check imidiately if works or not, when having selected 'skip' for root node in file-list and see if 'size' changes to not list the old full size anymore and to instead what's checked next, to download. The reporter making me aware of this, rez, has no issues in deluge-console or in a previous distro-release of deluge 2.0.3, though personally is neither here nor there, when checking a bunch times repeatedly, with restarts etc. Sorry no actual help to provide, and thanks for reporting here.
mhertz wrote: ↑Mon Dec 11, 2023 8:07 am
For me it happens much less when having prioritize first/last pieces disabled, or with libtorrent 1.2.x, but not fool-proof workaround though.
You were quite right by assuming that the prioritize first/last pieces checkbox was enabled on my side. I've unticked one and shall watch for some time in order to make any conclusion regarding the validity of your statement. Thanks.
BTW, that option did this always, by mistake, years ago, and was believed to be fixed later. As it's not a full workaround, then though not the culprit imho, atleast fully, as atleast here just skews the success-rate considerably, though at one daemon restart it started happen 3 out of 3 times, where all other times had small percentage fails only, so your milage may vary, unfortunately.
I'll make ticket later today, or tomorrow, and link in your thread, and rez's, thanks guys. (I'll edit in ticket link here later too.)
mhertz wrote: ↑Mon Dec 11, 2023 10:13 am
BTW, that option did this always, by mistake, years ago, and was believed to be fixed later. As it's not a full workaround, then though not the culprit imho, atleast fully, as atleast here just skews the success-rate considerably, though at one daemon restart it started happen 3 out of 3 times, where all other times had small percentage fails only, so your milage may vary, unfortunately.
I'll make ticket later today, or tomorrow, and link in your thread, and rez's, thanks guys. (I'll edit in ticket link here later too.)
Thanks. The problem still exists actually, even after changing the setting as advised.
Attache below is the today's bit of evidence (skipped item has been downloaded)
It happens mainly when you uncheck the files checkboxes while adding a torrent/magnet.
Those checkboxes do set the state to Skip, but it downloads anyway.
I looked at the code in-depth now and troubleshootet it, only using libtorrent 2.0.9 for now(with
deluge 2.1.1). and again for me only is an issue with 'prioritize_first_last_pieces' enabled, and I
can see why from code and my troubleshooting, but in short, disable that option and need readd the
torrents for effect.
I'll update the ticket I made later, with some more details, need run more tests also, but here
follows some info for the curious reader, or else simply ignore.
in a bunch tests here, from GTK-UI but is same in all UIs as same underlying core functions utilized
regardless, then without prioritize_first_last_pieces enabled, then the file-priorities vector is
generated correctly by deluge and feed to libtorrent, hence works, but with before mentioned option
enabled, then after that file-vector generated and sent, then also the piece-priority vector queried
from libtorrent, and for each file then deluge changes first/last 2% ranges of pieces to 7 for high
priority, if not 0 originally, hence should skip enabling those ranges for skipped files. However,
as said deluge initially gets the full pieces vector from libtorrent but it's an old not yet updated
version sadly(the file-priority vector deluge previously applied not taken effect just yet), and then deluge applies it's changes to needed areas through some clever
list-slicing/comprehension, but then thinks none files skipped as none is 0 as not updated yet, and
then finally feeds full pieces vector back to libtorrent. Piece priorities takes effect over
file-priorities still, and when applying file-priorities, then libtorrent rewrites piece-priorities
to match, but not other way around. So that is why the *.part fil grews so big, as the skipped files
indeed skipped from file-priority vector correctly. but as all the pieces still defined for
downloading in pieces vector, then indeed is, just placed in said *.part file as per spec, since
skipped. There's also a warning in libtorrent API docs about being cautious when using both file and
piece priority manipulation - there's an alert utilized for this btw, for when priorities changed
correctly, which I guess would be propper solution to utilize, instead of me hackishly just adding a
slight delay - well I didn't even actually need delay, as a '0' in a twisted callLater was enough,
as guess the time for running call was enough even.
Lastly there's a bug, where pop'ing an element out of the options dict, then despite done I
tested(trying do again later gives key error), then doesn't show it when printing it or testing for
elements in it(likely related to the self part somehow), so for that reason the
'set_prioritize_first_last_pieces' function runs twice, but isn't the issue as did change that
locally without effect(it's in set_options() of deluge.core.torrent, where I changed the pop to
options dict to be outside assignment to self.options, to make it work right. Anyway, just some
info, and i'll refrain upload my changes, as simply disabling offending option enough. Think i've run 100 tests now or so on this, the last days lol,
Deluge
