Deluge Forum

@mhertz

I give a feedback

While i wanted to try another theme, i wasn't able to reinstall deluge. Even if i dessintall it before reinstalling it. some files are un-re-writeable was told me during installation offering abort or cancel those files.

For a certain folder in windows which i wanted to cleanup manualy since windows told me a problem when uninstalling (gtk3) i cannot open an see what's in (an delete) and i can't have hand over permissions, in any maners. The files i mention above where in that folder i remember.

Don't know what happens but i reverted to prior stable and safe state because that's very suspect - to me - to not have hand in anymaners on folders on windows...

Anyway not having the hability to upgrade Deluge is a major problem.

Sorry to hear that. The only thing I can think about, is that you maybe did run the exe with the patch twice, since it doesn't say anything about finished or even started, which I shouldn't have done in hindsight. I made those exe's a little to quick and should have added some precautions I see, or atleast a "finished OK" dialog. What I'm referring to, is that at first run of the patching exe, then it patches the file and quits. If you then try run it again, then it will say you have already done that and so will you now revert the change and to press y or n for that. This isn't my doing but the gnu patch tool I use(though that message probably can be switched off, which I should have). Then I brilliantly have hidden all output, though never foreseen anyone would run it twice, and now the file to patch remains held open in memory and you cannot reinstall deluge fully untill after a reboot or killing patch.exe from taskkill.exe or taskmanager.

Sorry again for your troubles.

That's right i remerber having done it two times and i think i understand now why i wasn't able to reinstall due to task in memory and the inaccessiility a cetain files.

Don't move anything ( at least for me) and i'll give a feedback.

I improved the patching exe's a little, also because I was thinking about reusing them for possibly feature requests i.e. just swapping patch out for another, rebuild and upload, as I automated the process, as per usual

Anyway, I made following changes:

Never hangs in memory.
Shows message to know is finished.
Supports re-running exe's for reverting changes and vice versa.
Allows selecting alternate deluge install-dir to patch deluge from.
Dropped batchfile and instead utilize internal commands of control-file.

patch.exe: (Always enabled delete_files checkbox)
http://s000.tinyupload.com/index.php?fi ... 2841595039

patch-2.exe: (Bypass remove-torrent gtk-dialog and delete files always)
http://s000.tinyupload.com/index.php?fi ... 9770687728

About language-support, I see what you mean, there is something wrong, or maybe simply not updated to deluge 2.0 yet, I dunno. I checked with opening a command-prompt and running "set lang=fr" and then "C:\Program Files\Deluge\deluge.exe", and there wasen't any french there, except the 'help > about' dialog came up with french title and buttons but not the main content, plus having that dialog translated solely, is rather useless obviously. I then tried the same with setting lang to da, as my place of origin, and most things where translated pretty much, except though the lowest dialog of screen and top menu-bar and preferences-menu.

@ mhertz

In a word : Thanks . Utorrent had this ability (by the way of a checkbox in parameters) but since it seems plenty of security issues, i was asked to change of client to be able to share torrent files.

The ability to revert - you scriped - is very smart, it's (finaly a new pluggin ?) already perfect for me now but who knows ?

If i had a last wish (i strongly believe at the moment ) for deluge is that in Utorrent we had the hability to open the file of the torrent in the main windows (by double clicking a line) whereas in Deluge you only can do that in the subspace of Deluge.

If the file was a film it was running the default player, an exe, it was executing it, ... If the torrent was a folder (in the default download folder of deluge) then it was opening the explorer and the specific folder...

I'm now used to the specific way of deluge but that was an old good time .

Il will be be there if you've new things to translate .

@PhiliP

You're very welcome Hmm, sorry that is not really something I think I am able to do, i.e. check if file(s) from loaded torrent is movie and start default player streaming, or otherwise explorer.exe for files/folders etc. I am very much in absolute beginner stage of python I can assure you, unfortunetly, hence only very easy stuff I can do for most part. Maybe there are a plugin giving you some of that functionality, though I haven't checked myself though.

@all,

I have updated the installers to use newest python v3.8.2.

There was several changes needed and various stumbling-blocks but finally it is in a working state. Several fixes needed to gvsbuild, though the dev there beat me to the final fix of my posted ticket there, but no worries as much more elegant than my crude ways. Then all three libtorrents needed rebuilding to be importable by py38, and finally deluge needed a few things also needing to take into account to get working properly.

Anyway, one really nice thing about this, is that the python devs finally fixed the issue of conflicting dll's from system32 folder, and even though I seemingly fixed atleast most of them by merely copying files around the filesystem where found needed, to block the hardcoded system32 dll lookup that took precedence before if not in same dir, then there shouldn't be any new issues coming of that, and I could also remove those workarounds(extra file copies) I made before.This nice change though then also completely broke my hack to add to PATH for running session, but after alot of experimenting back and fourth and googling the hell out of it, then finally got it working again through the newly added os.add_dll_directory() function and some preceding logic needed beforehand and whatnot.

Then I added a py38 related patch I got from arch-linux which also uses py38 latest version, to both installers to avoid an annoying error printed all the time about a gettext/locale issue. For the stable installer I had to backport a commit from develop branch(so included already in dev installer), as logging wasen't compatible with py38 yet in master branch(stable/2.0.3), and so needed a fix there.

Note, 3'rd party plugins you have installed already, will probably need to be renamed to have 3.8 in name instead of 3.7, and the same when installing new plugins and not having any 3.8 versions available, as some don't, but renaming usually works. If plugin not having any py-version listed in name, then not an issue usually. If renaming doesn't help, then see if there is any py38 version available from plugin author. I'll add this to first post also.

Lastly, there where today released new gtk3 release v3.24.18, but it's a very small update with zero changes/fixes regarding our use of gtk3 for deluge here, so i'm not going to bother rebuilding complete gtk3 stack for no change whatsoever, and we don't have any dialogs in deluge listing gtk3 version neither which otherwise would be only reason for me doing it, e.g. like with libtorrents at times precedingly, so we're still on next-last version from a couple of weeks ago still.

@ mhertz

I've updated with a fresh new all reinstall, your beta version of yesterday evening, last patch-2.exe (thanks again), updated labelplus with 3.8 (thanks) version and it works like a charm.

I think i 'm gonna pass to production status, swipping 1.15 to you beta 2.0.

Thanks for feedback Philip too and i'm glad to hear it's working for you

@all, again remember plugins now need 3.8 py version in filename(or no py version at all, like with e.g ltconfig-2.0.0 plugin), like Philip stated above, so rename or download new version if available in py3.8 version. Like I read elsewhere that yaRSS2 doesn't work on py38, but that's not true as simply needs a rename that's all, as there's no py3.8 version available for download neither. The same plugin filename-changes was needed when I previously changed from py36 to py37 in these installers. Not related to my installers specifically though, but a general issue with deluge and python, e.g same issue exist on Linux with deluge. I have updated first post also, with this important notice too.

Btw, I read there are some nice performance and lower-memory features of py38 so hopefully that will translate to deluge too.

Last, before when I said the newest gtk3 from yesterday didn't bring anything we could use to the table, then I meant it only featured Wayland fixes, which we don't use(wayland), and docs, makefile and Latvian translation fixes(deluge uses own translations). If simply one single commit can be used for deluge, no-matter how small one-liner or whatever, then I'll gladly rebuild whole gtk3 stack for that, so it's not because I'm being lazy about it.

Edit: Rebuilt latest libtorrent 1.2.x yet again, to catch up, and rebuilt installers with it. Again, as I said some time ago, I normally don't announce libtorrent rebuilds in installers, as happens pretty frequent, atleast once a week I'd say round-about, and if interested you can check modification date on the installer links and match to commit log of libtorrent if curious. I added it here this time, since anyways was editing the post regardless.

Just wanted to add that I'm considering removing again the libtorrent 1.2.3 option in installers, but will think little more about it, as doesn't hurt either, but just seem pointless now. Also as there already is libtorrent 1.1.x if needing an alternative to default 1.2.x, but as said will think more about it first. I'm pretty conflicted about it honestly, and also actually consider instead keeping and making libtorrent 1.2.3 default, to avoid error messages confusing people to think somethings wrong(with trackers), and then having 1.2.x as optional component, just like 1.1.x.

Anyway, reason being that after changing my virtualbox network settings to bridged instead of default nat, then I suddenly now also could reproduce the tracker error, in my win10 VM, others here previously reported, and my reasoning for adding libtorrent 1.2.3 in first place.

I gathered debug logs, also of a libtorrent 1.2.3 run so as to show the issue side by side, one working and one not, then posted new ticket on libtorrent's github. Arvid then responded that it's normal behavior, and the UI shouldn't show the tracker as failed: "One listen socket failing should not make the UI suggest the other announces to the tracker failed". I'll submit new bug-ticket about this on deluge bug-tracker tomorrow(Edit: Done). So if you get your trackers in error state because of this, then a non-issue, as tracker is working anyway.

The issue is that libtorrent after v1.2.3 tries contacting tracker from not one, but all listen sockets(accepting incoming connections) it can find, and lo(loopback) being one of them, and as lo doesn't have internet connectivity then it fails for that connection try only, while the other (main) connection doesn't fail, but deluge doesn't check if there are other working connections when receiving a tracker error alert from libtorrent(as newly introduced behaviour), hence the issue we se here. I believe it's the "multi-homed" commit that's responsible for this, to support several interface routes which was an issue in libtorrent before that commit.

I just re-read the ticket again, a bit more carefully. Do I understand correctly that the issue is that the 127.0.0.1 listen socket announces to trackers or that it fails?

It's supposed (and expected) to fail. Otherwise you would end up announcing twice to the same tracker. The error should be (iirc) no_route_to_host.

Every listen socket (that can accept incoming connections) announce to the trackers. Some of the local listen sockets cannot reach the tracker, because they are limited to a local network. In other words; the loopback listen interface is expected to fail. One listen socket failing should not make the UI suggest the other announces to the tracker failed.

Source: https://github.com/arvidn/libtorrent/issues/4529

I've found something wrong, not THAT wrong but somewhat...

That's about the size of the windows of Deluge. The only thing that's goes right is the full expand button : It fulls expand but :

While closing it to tray (with the check box checked in parameters that permit to deluge to go to tray instead of closing when cliquing on close button of deluge), Deluge doesn't remember last full expand state and revert from tray to unexpended size (and there is no way to expand it manually from side hands, it lacks a little bit to cover the widht of the screen)

That's what i wish, deluge to remember at least expand mode when getting in or getting ou to tray, because that's how i use it, expanded mode, 99% of time.

Why is your installer "un official". Couldn't we go to a beta release since i haven't seen anywhere else better support for Windows installer ?