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

[mhertz]

I have uploaded a zip with a portable deluge 2.0.3/libtorrent-1.1.13 with some added before removed files and moved around other files which should bypass the issues of them trying to be loaded from system32 or elsewhere. This currently breaks the win32 theme, for currently unknown reason, so shows with adwaita default gtk3 theme now, but is just to test. I kept the python version the same, as shouldn't change anything. If not starting, then try delete first session.state from %appdir%\deluge folder and try again.

<REMOVED>

Thanks in advance.

Again, when testing and it fails, no matter which version, then please always try deleting session.state from deluge profile folder and trying again.

EDIT: Removed link, as I believe I found issue and rebuilt both installers with fix.

[mhertz]

Libtorrent was updated 8 hours ago, so I built latest libtorrent 1.2.3 and updated both installers to install this by default, instead of previous 1.2.2. There where additionally updated 1.1.x series of libtorrent, so 1.1.14, instead of previous 1.1.13, but my first try of building it failed with an error, so i'll have to see if I can get it to build somehow, but I don't have time currently, so that will need waiting and hence 1.1.13 still is offered as optional checkbox, instead of newest 1.1.14 unfortunetly.

Edit: Fixed the issue and rebuild both installers with optional libtorrent 1.1.14. I needed apply a patch to boost to get libtorrent 1.1.14 to build when using python 3.7.x.

[mhertz]

I just tested that if you have an old cairo.dll file in system32, then installs from my installers, or Cas's manual install instructions, don't start, and also neither the test version i uploaded which hopefully should fix that, unfortunetly. I don't really think I can do much about it honestly, and note, this is not on clean windows installs, but some app has placed the file there for you and probably left there even if uninstalled later. Untill, or if, I find a solution to this, then you gotta delete the file in system32, or rename to cairo-bak.dll etc. There could also be other files acting likewise I dunno, but just found this one out just now by testing different things. Sorry for inconvenience.

[mhertz]

The issue I found of deluge not starting if having old cairo.dll in system32 folder(or elsewhere in PATH), I have fixed now and rebuilt both installers.

[zmaster_ar]

Hi there, i'm very thankful for all the effort you're making for us windows users. That said, i can't make this work.
I'm using your last (today) version, that is Client: 2.0.4.dev23, Server: 2.0.4.dev23, libtorrent: 1.2.3.0Copyright. Deluged and web client are working ok, but can't start the client.
I'm having the following error:

Code: Select all

The procedure entry point inflateValidate could not be located in the dynamic link library C:\Program Files\Deluge\gvsbuild\release\bin\libpng16.dll

And the logs are the following:

Code: Select all

** (python.exe:8564): WARNING **: 21:30:09.867: Failed to load shared library 'gdk-3-3.0.dll' referenced by the typelib: 'gdk-3-3.0.dll': The specified procedure could not be found.
Traceback (most recent call last):
  File "C:\Program Files\Deluge\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Program Files\Deluge\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Program Files\Deluge\deluge-debug.exe\__main__.py", line 9, in <module>
  File "C:\Program Files\Deluge\lib\site-packages\deluge\ui\ui_entry.py", line 143, in start_ui
    ui.start()
  File "C:\Program Files\Deluge\lib\site-packages\deluge\ui\gtk3\__init__.py", line 43, in start
    from .gtkui import GtkUI
  File "C:\Program Files\Deluge\lib\site-packages\deluge\ui\gtk3\gtkui.py", line 26, in <module>
    from gi.repository.Gtk import Builder, ResponseType
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "C:\Program Files\Deluge\lib\site-packages\gi\importer.py", line 145, in load_module
    importlib.import_module('gi.repository.' + dep.split("-")[0])
  File "C:\Program Files\Deluge\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "C:\Program Files\Deluge\lib\site-packages\gi\importer.py", line 146, in load_module
    dynamic_module = load_overrides(introspection_module)
  File "C:\Program Files\Deluge\lib\site-packages\gi\overrides\__init__.py", line 118, in load_overrides
    override_mod = importlib.import_module(override_package_name)
  File "C:\Program Files\Deluge\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Program Files\Deluge\lib\site-packages\gi\overrides\Gdk.py", line 83, in <module>
    Color = override(Color)
  File "C:\Program Files\Deluge\lib\site-packages\gi\overrides\__init__.py", line 195, in override
    assert g_type != TYPE_NONE
AssertionError

I renamed the data folder, and it created a new one with just a 1 file, but the problem persisted.

It's obviously something in my pc, cause i just made a VM with a clean windows 10 install and i can run it there ok. But do you have any suggestions of where it could be the problem or some guidelines to make it work?

[mhertz]

I rebuilt 3 times today, so do you have a file named cairo.dll into your folder where you installed deluge? (%programfiles%\deluge), which means it is the latest.

Yeah, it's an issue of conflicting files from '%programfiles%\deluge\gvsbuild\release\bin' and '%windir%\system32'. With the freetype issue some time ago, it was enought to copy it from '%programfiles%\deluge\gvsbuild\release\bin' and into same folder as deluge.exe, but this last cairo issue weren't enough to place next to deluge.exe but needed it copied also in a subfolder further down the filesystem-hirarchy I found by try and fail, as It needs to also be placed next to pyd files related to that file too sometimes like here.

Sometimes it's the file in the error, and others not so much. If I had your issue, I'd start with copying libpng16.dll from '%programfiles%\deluge\gvsbuild\release\bin' and into '%programfiles%\deluge' and try start deluge.exe then.

It could though also be other file related to GTK, like I believe zlib or xz or something like that. I don't think it's needing gdk-3-3-0.dll even though listed in one of the errors, but that file is usually referenced no matter what, and I have previously tried that.

Anyway, to find out what's needed I need to reproduce first your issue, and so i'm looking for a libpng16.dll file online, different from mine provided, to place in system32, as I did same with freetype.dll and cairo.dll before, but untill now all of them are 32bit and i need x64 obviously, but will look more.

The really strange thing is that simply adding the dir with the files('%programfiles%\deluge\gvsbuild\release\bin') to your PATH before system32 didn't help when testing this. I actually also does this by a trick I made in a pth file under Lib\site-packages(path.pth). I'm reading up on if there is anything else to do to force a specific folder, or override other, or even why it works like this with doesn't respecting order of PATH like normal?

Anyway, if we're lucky it is enough to copy the libpng16.dll mentioned earlier, so please try that and report back, which would save me some troubleshooting. If not working, you can in meantime see if renaming that file to have bak in name from your system32 folder helps, or if feeling adentures, then if you have any zlib or xz file there, then try the same if the libpng16 didn't work.

Also, i'm retirering for the night, so will need some time before looking at it again.

[zmaster_ar]

Copying the file into %programfiles%\deluge didn't do the trick, and i don't have it in windows/system32. I'm retiring for the night too, so have a nice rest

/late edit
I used your last build (i have the cairo.dll file in deluge root path)

[mhertz]

Thank you Also, I appreciate you testing these things and reporting 'em back, so as to save me alot of time going on a wild goose-chase for propperly unrelated libpng16.dll issues.

I'm as said reading up on if I can somehow "hack" from python the default module search order, as I just found out that the PATH is only used for that after several other items, like SXS side-by-side dirs and system32 etc. Folder of app is used pretty much first, but then also is needed in folder of related pyd's further down the filesystem, like cairo.dll before + I need knowing actual problematic file to place there in first place.

My first tries have failed, so i'm honestly not sure I can ever fix issues like these, but i'll keep trying when time permits, and also i'm looking into if possible to transfer the install into a virtualenv and if that would even help - probably not for this issue - I do that often on linux(using virtualenv's), but don't know how it will work on windows i.e. sure the python is selfcontained, but will windows dll module search order still apply, which is the main issue.

In mean time, the only thing I can suggest, is running dependency-walker and profiling deluge.exe and pasting me the log. It's honestly hard for me to fully understand these logs, but they sometimes help me narrow the issue down, and have come in handy several times for me already during making these installers.

If up to it, then here's instructions:

Download dependency-walker zip and unpack: http://www.dependencywalker.com/depends22_x64.zip

Run it and press ctrl+o and select deluge.exe and ok. Some error(s) will show.

Press f7, select the checkbox of third last option(for enabling full paths), and press return. Some errors will show.

Press with mouse on some text to activate cursor on lowest window log, press ctrl+a and ctrl+c, quit dependency-walker and paste the copied log into a new empty document you make e.g. using notepad.exe or whatever.
(There's an option already in dependency-walker for saving the log, but it saves alot of other stuff too(unless i'm missing a second option somewhere), and where over 5mb big in my test of this, so better do it manually and only get the text log.)

You can attach the log txt-file in a post here on forum, or post here in codetags, or e.g. paste to pastebin and post link - whatever.

As said, I don't know if even being able to decipher the solution for your specific issue from that, but it's surely better than now where i'm working in blind, as need to be able to reproduce the issue you have, for actually fixing it.

Thanks again.

[zmaster_ar]

Thank you Also, I appreciate you testing these things and reporting 'em back, so as to save me alot of time going on a wild goose-chase for propperly unrelated libpng16.dll issues.

I thank you so much for this. And don't feel pressured in the very least to do it. I know it's something in my PC so...

Anyways, here is the dependency walker log (https://gist.github.com/zmasterar/2cb28 ... b89aefbc0c).

If it's of any use, i did a search for any libpng16.dll in my C: drive and i only found it in a Calibre folder (as i said, there isn't any in system32 folder).

I didn't think it should meddle with Deluge until, after i did the dependency walker and realized Calibre was in the Path. I renamed that libpng16.dll to libpng16.dll.bak, but no luck.

I really hope you can find some solution, but if you don't don't fret. Although i prefer the gui, i can get around with the webui.
Thanks!

[mhertz]

Thanks mate, I appreciate that!

I have fixed your issue and rebuilt both installers. I could see from your log(thanks for that), that your ruby install dir added to PATH, made deluge use zlib1.dll from there instead of the one provided with deluge. I made two changes, I needed make a slight tweak to my path.pth file to add deluge's needed dir infront of PATH and not at end, which was an oversigth but always worked in my tests before, except this one I now could reproduce from your issue. This tweak will though not fix if having same-name old conflicting files in system32, as with freetype.dll and cairo.dll, where I have to copy files around to make it work, since dlls from system32 always are loaded before PATH unfortunently, but I fixed the issue of if having zlib1.dll in older version in system32, by copying the file into deluge\lib\site-packages\gi\ - found by trial and error, as copying just to main deluge dir didn't fix it.

hopefully most situations is already fixed now with cairo.dll/freetype.dll/zlib1.dll overrides, and the fix for stuff added to PATH yourself, and i'll continue looking for more universal solution.

Thanks again for reporting and helping to find a solution with me, so as to make the installers more robust, much appreciated mate.