*OLD-THREAD - SEE NEW* [Unofficial] Deluge 2.0.x installer

Specific support for Deluge on Microsoft Windows OS
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Sorry, forgot link before. I didn't either track this myself when making installers(didn't think PR would change, and also forgot monitoring it just in case), and so just "fell" over it(updated PR) by accident, while being on deluge github's PR section looking for if anything interesting added lately to possibly include for myself on linux if worth it. Also, I added the deluge bugtracker ticket I submitted about this, that spawned this whole tihing, just in case.

Djlegolas PR:
https://github.com/deluge-torrent/deluge/pull/289

Ticket #3384:
https://dev.deluge-torrent.org/ticket/3384

Nice btw :)
petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

New release!

Post by petersasi »

  1. The default ncurses in Python is not supported (and does not work) on Windows. Try to include windows-curses 2.1.0 in the hope to revive that - it should have a hack to make it work (thanks for the report @mystikfox!) EDIT: not it no longer misses ncurses itself, but that the module 'signal' has no attribute 'SIGWINCH'. will need further investigation, probably deluge patching (which is something quite distant from my current capabilities).
  2. PR by djlegolas regarding ignoring untrue libtorrent 1.2.x tracker errors from UIs was updated - replaced the old URL in the deluge-build\deluge-{dev,stable}.cmd scripts
  3. Refactored the folder cleanup logic in deluge-build\deluge-{dev,stable}.cmd scripts to use a list from a text file ("%programfiles%\deluge\" added to all) instead of making the previously 12 lines of "rd /s /q" into 170+ in the script.
  4. First slimming of the installer by profiling to find files never touched,removed - this round only strips away complete folders unused:
    - test / tests / unittest folders: 18.2MB
    - demos folders: 0.9MB
    - gobject-intospection folders: 1MB
    - legacy folders from the Adwaita theme: 7.6MB
    - ensurepip folders: 2MB
    - doc folders: 0.7MB
    Result:
    - uncompressed set of install files down from 226MB to 202MB
    installer size is down 11MB (including the newly added windows-curses)
    - the profile log, filelist and Excel pivots used are uploaded to the
    CleanUpInstallerByProfiling folder in the dowlnoad site.
  5. Replaced the remaining genric variable names with meaningful names.
  6. Decided to start writing ChangeLog.txt on the download site :-D
Last edited by petersasi on Sun Jun 21, 2020 8:03 am, edited 1 time in total.
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Impressive, thanks for your continued nice work on this mate, great to see honestly :)

Im gonna remove the mention in first post here of "This post is kept up-to-date with relevant information so no need to read through the whole big thread to catch up.", and instead make a note about checking ChangeLog.txt at the download-link for changes. Good idea btw, i've previously thought about linking to subsequent post of yours that you could keep up to date with notes and such and change at will, or instead say to just send me notes whenever wanting something edited into first page, but a changelog under download-link is a great idea imho.

Btw, totally unrelated, and you probabky know, but just in case. Even though it looks like it on that page I send you to monitor libtorrent changes, then RC_1_2 branch which I used for 1.2.x, is stil 1.2.x and not 2.0.x, as libtorrent 2.0 work is made and released in RC_2_0 branch, but just written confusingly(wrong i'd even say) on that page I linked you, if still using that. That said, I haven't tested your builds since your initial test-runs, and so believe from filenames and comments later on, that you not use RC_1_2 branch anymore and instead release stable seperate versions, so using either git release tags or source tarballs or whatnot, so then wouldn't apply to you anyway, but just in case.

Again, appreciate your efforts mate, and thanks for the community contribution :)

Edit: Hope it's good enough my addition in the bold font notice initially in first post, where I just appended: "Lastly, ChangeLog.txt on the download site is kept up-to-date with latest changes so no need to read through the whole big thread to catch up", and deleted the line a little later where I stated the same, just not mentioning ChangeLog.txt but "first post" instead. Otherwise give me a shout if wanted it changed and/or wanting other things added/edited to first post, now or later on.
petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

Re: [Unofficial] Deluge 2.0.x installer

Post by petersasi »

Hi mherz,
The update to the first post here is great, thanks!
As for libtorrent: I still only regularly rebuild 1.2.x and 1.1.x, but monitoring the libtorrent repo most of the activities there are already are in preparation for the 2.0 release that will have support for the new, more secure torrent 2.0 hashes as well as file operations converted to mapped (zero copy) file IO.
Still hoping that they will keep the API backwards compatible but will have to wait and see.
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Thanks mate for elaborating :) Nice changes in 2.0 indeed and yes, hopefully will not break and/or full support for it added in deluge at some point. I didn't see direct memory mapped file IO coming, as remember Arvid stated several years ago that he believed an application level file cache still would make sence, for several reasons, when someone asked him what he thought about the directly memory mapped IO design rtorrent used(mmap), but must've had a change of heart.
petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

New release!

Post by petersasi »

  1. Created a patch to swallow the AttributeError because of not having the signal SIGWINCH on Windows in Python windows-curses. Now you can run:
    deluge-console.exe status
    deluge-console.exe info
    etc.
    https://dev.deluge-torrent.org/ticket/3409 is the ticket submitted with a patch for this. I hope this is enough for what you need it @mystikfox!
  2. Created a patch to replace the "Deluge-console does not run in interactive mode on Windows." message and exiting. Instead we just log a debug message and carry on. Now the interactive UI starts but does not accept any input. The log is full of a twister error for win32select. I am stuck here, will have to ask for the help of the devs.
    https://dev.deluge-torrent.org/ticket/3410 is the ticket submitted with a patch for this.
  3. Published patches in a folder on the download site.
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Awesome work there, I couldn't fix that myself, so much impressed :)
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Sorry petersasi, just quickly wanted to say a slight warning to people I just found. I wanted to quickly test if deluge was too affected by an issue I just saw at a family members PC using qbittorrent on windows, after checking that it didn't happen on linux.

Anyway, I noticed that if using a VPN and not having it bound to an interface, then with libtorrent 1.2.6 and ipmagnet, then it reported both my VPN's IP and then also my real IP. I checked in linux on my own deluge install and libtorrent 1.2.7 and there it doesn't happen(I disabled my namespace tun0 lockdown setup for the test, as else wouldn't see it regardless). The family member PC using qbittorrent had libtorrent 1.2.6 included(latest windows v4.2.5 installer), and only got fixed if binding to TAP interface of VPN in settings(which usually is done anyways, but regardless).

It have been reported before at times with earlier libtorrents between 1.2.3+ and up, and when reported then once stated that if e.g. checking the swarm from another PC on another network, then the VPN IP is showing activity(up/down-loading) under 'peers' tab, but the real IP shows no activity, which is nice, but is still listed there, which I would personally not want my real IP to be sent to trackers and shared with the swarm, regardless off it not showing any activity. Granted it can very well be that you will not get into trouble this way, because of the no activity, so maybe you will not be "logged", but personally I wouldn't take the chance.

Note, this isn't a deluge issue(or qbittorrent) i'm pretty sure, and is a libtorrent issue, seemingly happening on windows only, when not binding your IP, on versions above 1.2.3.

It's probably that multi-homed thing again making this be possible, so I would myself in that situation use libtorrent 1.2.3 or latest 1.1.x from the installers(sorry, didn't check latest 1.1.x, but pretty sure not affected by this, as no multi-homed support. I only tested 1.2.7, 1.2.6 and 1.2.3 on windows, and 1.2.7 on linux, and then didn't wanna bother anymore with it, sorry. As said, i'm not affected as on linux, plus wouldn't be regardless as using namespace tun0 lockdown which negates this ever being a possibility).

Just a FYI(/PSA?) to people reading/using this with a VPN and not binding it's interface in deluge. I know binding works(fixes this) only from qbittorrent, and quickly testing binding outgoing interface to tap device name or IP of deluge didn't change anything, but don't know if I did it wrong as only a quick test, and didn't check/debug fully, and so just tested ipmagnet twice extra, one with adding tap interface name to outgoing interface option, and one with instead adding assigned local IP of tap interface. I should just in case also have configured the incoming binding setting, but didn't at the time. Actually also did extra test with public IP of tap interface as outgoing interface bind, which I'm guessing is wrong, but just in case, and without luck.

Btw, afterwards tested out deluge-console on windows after petersasi's nice fixes, as curious, and all I tested from command-line worked i.e. adding, removing, checking, moving, pause/resume, checking/changing config options, list/enable/disable plugins, etc, so awesome! Globbing is now supported, either for torrent name or ID, which makes it much convenient when wanting to filter a loaded torrrent for manipulation(and even better than the previous and already nice "begins-with" functionality), e.g ipMagnet torrent can be filtered through e.g. *M*, or i* etc in e.g. info, rm, pause/resume commands etc. Also, "info -v" is more verbose, e.g. showing tracker name/status etc, missing normally from 'info' in deluge2 consoleUI. Starting interactive mode didn't show errors for me, but neither worked as stated, and couldn't connect to daemon or press any keys/commands, but that never worked neither in deluge1 with it's older version of console UI and also only supported command-line access, i'm guessing because of missing curses on windows, and the curses dependency in rewritten console UI of deluge2 even in command-line mode, I'm guessing is a bug/oversight, as curses isn't used non-interactively as far as I'm aware.
Last edited by mhertz on Sun Jun 28, 2020 10:17 am, edited 1 time in total.
petersasi
Leecher
Leecher
Posts: 93
Joined: Sun Nov 17, 2019 8:09 am

Re: [Unofficial] Deluge 2.0.x installer

Post by petersasi »

Hi MHerz, I have been reading up on this in the libtorrent github issue discussions: this is the default behavior, you have to bind it to your vpn interface or ip address only to makes sure this does not happen.
It's even part of the wiki: https://dev.deluge-torrent.org/wiki/UserGuide/VPN
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: [Unofficial] Deluge 2.0.x installer

Post by mhertz »

Hi petersasi :)

You shouldn't need bind your torrent client to your VPN interface/IP, as the VPN overtakes the default route by default in normal/regular setups. It's nice to do however, for kill-switch functionality and specifically needed when using manual routing in your VPN setup e.g. also as per your wiki link.

I have added a ticket on the libtorrent github for anyone interessted. Maybe I am misunderstanding something i.e. in my way of testing this(just ipmagnet website and not wireshark etc), but if my finding is correct about announces going out from both VPN IP and your own true IP, even when not bound to VPN interface/IP, then that is a bug/issue.

Again, this isn't related to petersasi's installer here, but strictly libtorrent only, and his installer already features two other libtorrents not doing this, that is if i'm not wrong in my testing.

I rebuilt a new libtorrent 1.2.7 to test, because was easier to compare to my own linux deluge which features libtorrent 1.2.7, and where doesn't happen there for me(with my killswitch disabled to test of-course).

Im not gonna spam(/interfere) this thread any more about this, unless being asked specifically, so please check the ticket if interessted in what outcome is thanks.

https://github.com/arvidn/libtorrent/issues/4803

Edit: If not reading above linked ticket, then latest outcome is that it's client/settings based and not an all-inclusive thing as I previously assumed, sorry. As said happens on open-source openvpn.net client(with windscribe and tigervpn, which was all I had available to test, but this issue here is about openvpn clients on windows and not VPN providers, but just added for full disclosure) and e.g. doesn't happen with windscribe's official client, but does if killswicth/firewall is disabled in it(and openvpn defined instead of default ikev2) - of-course I here refere to VPN not gone down, as that obviously would be the issue when having disabled kill-swich, but mean fully working up VPN and still announces sent from true IP additionally to VPN IP, though two others in other tickets, with same issue(one with airvpn and official client and libtorrent 1.2.5, so not a new thing seemingly), reported no traffic from own IP to swarm in this case, so atleast comforting, but still not good being even registered in swarm for copyright trolls to see and possibly use against you, which atleast in older times have occured(dmca letters) in such scenarios, as per an older paper released testing such artificially where the result was e.g. wifi printer IPs got served DMCA letters lol. In one of the qbittorrent tickets about this issue, a reply was made about it was normal and needed binding to VPN interface to fix, but that isn't however how Arvid intended it should work when designing/implementing it, and my report was news to him, though always a good choise to do however, and specifically needed as previosuly stated when using manual routing to seperate VPN traffic(except e.g. if using linux namespaces).
Post Reply