# BUILD_CONFIG="debug cxxstd=14 crypto=openssl warnings=off address-model=32 -j$(nproc)"
#DELUGE TORRENT CACHE UPDATE#
# git submodule update -depth=1 -init -recursive
#DELUGE TORRENT CACHE APK#
# apk -update add -no-cache boost-python3 boost-system libgcc libstdc++ openssl python3 & \Īpk -update add -no-cache -virtual build-dependencies boost-build boost-dev cmake coreutils g++ gcc git jq p圓-setuptools python3-dev openssl-dev samurai Based on that, i should be long after that version.ĭo you happen to know which of these defines end up being set on your platform? TORRENT_USE_PREADV or TORRENT_USE_PREAD.īased on my test using config.hpp from the build, it appears to be using preadv It appears to be musl 1.2.2-r3 with some patches ( ) from looking at the strings in the library as well as referencing the available packages. In qBittorrent, I don't see a way to disable the use_read_cache (which, I believe is on by default) but toggling coalesce_reads (to false) brings back or (to true) eliminates the errorĬan you check which version of musl libc you're using? I found these, could you be affected by these bugs? Working: use_read_cache = true works with coalesce_reads = trueīugged: use_read_cache = true, coalesce_reads = false I feel like I could have written a more concise report all of a sudden. Use_read_cache = true coalesce_reads = false To summarize, the problematic configuration is: And it only causes issues with certain cache settings. Given no system issues detected, I can't see how a simple read and hash would show something when 30+ hours of memtest86 doesn't show any challenge. Given that this is the same across more than one client using libtorrent, I'm setting my sights at libtorrent. So a file, unchanged on disk as per md5sum and torrent-checker, produces entirely random piece completion results. In qBittorrent, I've found if I turn on coalesce_reads ("Coalesce reads & writes"), I get to 100% as well, but with it off, still stop somewhere in the 90's. In fact, now that I've done that, I haven't had a single failure at all. So it's something that shows only with the read caching enabled. If I turn off 'use_read_cache' in libTorrent 1.2.x's settings, I actually get to 100% each recheck. Moreover, hours later, any disk write cache at an OS level would have long expired, especially at a restart of Deluge. If there was a system issue, I would expect that the torrent-checker would have shown an issue with the file or the md5 hash would have changed if any other product was raising issue.
dmesg shows nothing about I/O or anything relevant. The ext4 hard drives fsck without error when unmounted. System TestsĢ8 passes of all Passmark's memtest86 UEFI tests shows no sign of memory concern. but the md5sum on the file is still exactly the same as the incomplete file previously. Did a force recheck and it's at 94.7%, losing 863MB of data. Eventually let the torrent complete to 100% (though md5sum of the files shows the same as before). Tried turning off the "OS Cache" in qBittorrent but did not find a change in behaviour. Force a recheck and the file goes from 100.0% to 97.1% to 98.6% to 97.2% complete between three rechecks. Add the same torrent file and map the same folder. To narrow down between Deluge and libbittorrent, I compiled qBitTorrent 4.3.9 with libtorrent 1.2.15. I have made the files immutable to ensure no changes to them and yet, there are variations in how the torrent client sees them. MD5Sums of the file on disk (which I've done 20 in sequence without any variation in hashes) shows the file unchanged. Using torrent-checker at the command line, I get the torrent as verified OK every time without any failed pieces. Meanwhile, the file is unchanged on disk between completions. As a general note, I find more than I'd like of wasted downloads (likely due to the same hash fails during download) as well. Based on the piece_finished_alerts, the pieces it is missing differs each time the recheck is executed.Ī filesystem sync (linux), restart of deluge, restart of the system doesn't change things and this erratic behaviour continues. Further rechecks of the same paused torrent return 99.96%, 99.87%, etc completion. I force a recheck and the torrent goes to 99.91% completion. Start with Deluge 2.0.5 with libbittorrent 1.2.15 with a paused torrent at 100% completion.
0 kommentar(er)
