Deluge Forum

Its all good, just updating. Yea its a new issue in python 3/twisted. Also it appears the freezing issue might be related to it as well. When running from the freeze if you set the config to thin client it gives an exception something about missing attribute simulate() or something don't quote me on that exactly i dont have the error up atm. Which i think is related to https://github.com/pyinstaller/pyinstaller/issues/3390. Working on figuring this out now, might be using wrong reactor which might solve this quicker than I thought, who knows well see.

Interesting, thanks, I wish I could help out, but unfortunetly over my head honestly, but luckily we have good people like you looking into it Thanks again.

doadin wrote:Its all good, just updating. Yea its a new issue in python 3/twisted. Also it appears the freezing issue might be related to it as well. When running from the freeze if you set the config to thin client it gives an exception something about missing attribute simulate() or something don't quote me on that exactly i dont have the error up atm. Which i think is related to https://github.com/pyinstaller/pyinstaller/issues/3390. Working on figuring this out now, might be using wrong reactor which might solve this quicker than I thought, who knows well see.

While it does seem like this maybe the issue or at least part of it, im so far unable to find a solution.

Thanks for update doadin, hopefully you can figure it out anyways at a later time, though I understand it's a big effort to sort through. I did some googling on your posting details, but didn't help me much, which isn't a big surprice neither when considering i've never frozen an app in my life Thanks again mate, appreciate you're sticking to it regardless

I updated the python version in my installers to python 3.7.6 instead of 3.7.5, and also rebuilt both libtorrent versions with that version(contains both C++ and python-code). Not really important, so you don't need update, and was also for testing my building scripts, as there where still a few of the things I needed do manually and I finally got every single change made transfered to patch files and cmd-commands to be applied automatically and wanted to test everything still worked.

I now install deluge 2.0.3 from git through pip, instead of from pypi package, just like the dev installer and just use master(2.0.3) instead of develop(default) branch, because else missing debug exe's e.g used for nssm services. Before I included them from an extra temporary clone/build from git, and copy them over. I still though need the extra git temporary clone/build for both versions because plugins missing when installed from pip through git for some reason. You as enduser will not be able to tell a difference so this here is just for informational purposes and again no need to update for this.

Note, as said before, the newest python is 3.8.1(where I use 2 versions below that), but because needing a gobject wheel not available online for that python version, then to make it myself I need building both cairo and other dependant packages also in the process, which I failed during with some errors, or build instead the whole GTK3 stack to get it, and even though Cas forked gvsbuild from wingtk, and doadin made and provided batchfiles for building it, then the few times I tried, I failed too with various errors, though I also used VC-buildtools, which I have three versions off, and didn't wanted to experiment with installing/testing more of older editions, e.g the I believe main supported non build-tools older versions + I read some state that there can be compatibility problems with python 3.8 in regards to some plugins possible not working anyore e.g. one well-known deluge docker-maker(binhex) was requested to revert to python 3.7 because of that, so might not be a downside anyways.

Anyway, the initial install instructions from Cas and my first installers was using python 3.6.8, so we have come some way atleast

Ohh, I also forgot that a python 3.8 compatibility fix was added to deluge git-develop branch, so if changing to python 3.8, then I also will need backport that dev-patch into stable deluge 2.0.3, and also with the before-mentioned possibly compatibility-issues, then probably a good idea regardless to continue on latest version of python 3.7 instead, which also is officially supported and will recieve security/bug-fixes still.

Lastly, I along time ago included a patch posted by tobbez in the #3201 ticket about Windows-installer issues. The patch fixes a bug making deluge sometimes crash related to .ico tracker icons, so the patch disables those to avoid that, and posts a message in log about it being blocked just in case. Anyway my point was that I'm thinking about if I should make it optional and add yet another checkbox Maybe some aren't hit by this issue and then is annoyed by possibly missing some of the tracker icons. I dunno, I'll think about it some more, but maybe I should just leave it as is, as sounded like it was a pretty consistent issue afterall i.e:

The GdkPixbuf? (from gvsbuild) seems to have a problem that causes deluge to exit with an access violation¹ after attempting to loading a few .ico files (some of which are invalid). There are no messages in the debug log, but if running in a console it produces the following output:

c:\apps\deluge2\venv\lib\site-packages\deluge\ui\gtk3\common.py:75: Warning: cannot register existing type 'GdkPixbufGdipAnim'
return Pixbuf.new_from_file_at_size(filename, size, size)
c:\apps\deluge2\venv\lib\site-packages\deluge\ui\gtk3\common.py:75: Warning: g_once_init_leave: assertion 'result != 0' failed
return Pixbuf.new_from_file_at_size(filename, size, size)
c:\apps\deluge2\venv\lib\site-packages\deluge\ui\gtk3\common.py:75: Warning: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
return Pixbuf.new_from_file_at_size(filename, size, size)

For now I just patched deluge's get_pixbuf_at_size (in deluge\ui\gtk3\common.py) and prepended the 4 lines to it:

def get_pixbuf_at_size(filename, size):
# current GdkPixbuf is broken somehow and crashes after loading some number of ico files
if filename.endswith('.ico'):
log.warning('Returning blank pixbuf instead of loading file: {}'.format(filename))
return create_blank_pixbuf(size)

That prevents the crash, but obviously means you won't see icons for trackers that use .ico.

Source: https://dev.deluge-torrent.org/ticket/3201?#comment:32 (BTW, the other points he makes in that post also is fixed in my installers)

Um, I was trying to read as much as replies possible, but since I'm not a developer, all the techie stuff is going over my head . I have a question. How long before a stable official release of Deluge 2.0?

Doadin has made a great job in making the changes needed and he made it so it freezes/imports everything, but still there's a runtime error/issue making obstacles which needs more time to hopefully solve, and although probably on the right path then still not fully fixed yet.

There's so few people working on this(Cas and doadin) and they both have only limited time, so an exact time line I don't think you'll gonna get.

The official place to watch/look for changes on the windows-installer issue, besides git-commit-logs, is this ticket #3201 here: https://dev.deluge-torrent.org/ticket/3201

Sorry if translating something wrongly here doadin, and please speak up if having something to add or correct me in

I updated installers, but only backend/installer-script changes.

The method I used for overwriting the old install-dir when upgrading directly over, could potentially cause data-loss in rare scenarious, so changed that and I sincerly apologise for oversight in first place.

I did read cautions originally about the method I used, but didn't think it was an issue in our case, based on initial testing I did, but found out by testing it more in-depth now that it potentially was, and so changed that, + some other small changes e.g. testing for x64 initially and abort with a messagebox stating "x64 not detected - aborting"(so I have one less question to ask people about in bug-reports), and also changing install-script to unicode-target now after newest NSIS deprecated previously default ansi target.

Anyway, about the potentially, though rare, data-loss issue, was that during install while selecting to browse for another install path than the default, e.g. selecting %programfiles% directly, then the script does always add a '\Deluge' addition to that choosen path, so not installing directly in %programfiles%, but I then now noticed that if afterwards directly selecting the install path line and manually deleting the deluge end-folder part away, so the install-path now is e.g. %programfiles%, then afterwards the install will occure directly there. Now this isn't such a big issue, but the issue is that I added to delete that install-dir before upgrading over again, meaning deleting %programfiles%(or otherwise important path selected and afterwards edited the deluge end-folder away, or edited directly in important path from the get-go without any end-folder, as edit-bar doesn't add '\deluge' to path, only the browse-dialog does!) Granted this is imho a long-shot, but regardless, one can never be too cautious I then changed my script to include an extra function which runs just before the install happens, in the background, and checks for the string "Deluge" anywhere in $instdir(install path), and if not existing, then appends it to the choosen-path as end-folder, before the deleting and recreating install/upgrade happens.

Sorry again for oversight!

Sorry for posts in row(as usual ), but just wanted to let people know which doesn't monitor ticket #3201, that doadin is almost done with his awesome job at fixing the freezing of deluge 2.0, and just a couple of things still left, so I'm guessing we're not far from an actual official installer, so I will stop messing about with this unofficial installer here, and let the real pro's do there job, so just wanted to end this project by saying thanks to all the good people around here for good teamwork

I now have a semi-working build. I am able to crate a nsis installer(nsis is the program deluge has been using to make the setup.exe) that installs a deluge build, that works pretty like 90%, the only issue I am still having is getting the installed build to load the default plugins.(I have an idea but Ive been busy on the rest of this) can provide all the information needed ( @Cas ) to do so. There really is just a few minor changes needed.