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

[idiocracy]

No, i wasn't one of those reporting that issue, i just replied to let you know that i updated and that everything appeared to work as expected. Btw, did the lib update add anything new that might be of interest for high performance clients?

[mhertz]

Yeah, sorry mate, I got little confused there for a minute, and of course much appreciate all feedback in general, so thanks again for that

I don't think there was anything specifically exciting added since you updated, just some minor/small fixes and improvements here and there, but nothing really important I believe.

[goldenpipes]

First, mhertz = genius. Second, I am having a hard time with the web interface. When I try to add a url or file I keep getting "not a valid torrent" with nothing really in the log other than

[ERROR ][deluge.ui.web.json_api :79 ]

did you ever solve this? i cant seem to add via the webui either. magnets do work however.

i dug into this a little bit and it seems like when i added the torrent, it does upload to the host to "%appdata%\local\temp\delugeweb-#####\" i'm wondering if its a permission issue. any ideas mhertz?

[mhertz]

Sorry, but I cannot reproduce this on my end unfortunetly. I tested this, with an arch-linux and debian iso, both from magnet, torrent and torrent url. I tested this in 4 "directions", i.e. connecting to windows localhost daemon from windows webUI, from windows webUI to linux daemon, from linux webUI to windows daemon and from windows webUI to remote windows daemon("windows" in these scenarious means using this installer v2.0.3 on a win10 VM). I just manually started the daemon and webUI from deluge install folder for testing this, so not using NSSM services(with debug-exe's as per docs), startup folder, run reg-entries or scheduled-tasks, though doubt that would change anything if using such.

For some unfortunate reason there are some issues apparently that hits someone and not others with deluge2, though some of reported issues here, was seen on deluge1 too however, but regardless.

Sorry couldn't help you guys out with this i.e. if nothing else then gathering debug-logs to reporting it upstream, but as I cannot reproduce, then hard to debug/report.

[Paralel]

Has anyone managed to get the latest or recent versions of GVSbuild to work with the latest or recent version of GTK+ 3 with the latest version of Deluge? I've tried, and for some reason, it just straight out doesn't function at all. It doesn't appear to be a problem with GVSbuild and its compatibility with GTK+ 3, since I can get that to compile without any major issues. It appears to be a change in the way GVSbuild works that Deluge is not happy about. I try to run Deluge, and it will only come up in thin client mode. If I try to get it to run in Standalone, it does nothing, and then if I try to click on anything, it just locks up and stops responding. No actual crash though. I figure other people have probably run into this as well. I've tried running debugging, but strangely, it doesn't seem to put out any actual useful information. It says something akin to 'Unable to initialize standalone client' and that's it. When it locks up apparently it isn't sending out any errors or information, it just stops responding. I was a little disappointed. I was hoping for more verbosity.

Any ideas on what needs to be done?

[mhertz]

I'm sorry about your issue, but the lack of verbosity is because most don't have that, i.e if you try running it in a fresh win 7, 10 or whatever recent windows, e.g in clean VM, then it works.

Unfortunetly, because freezing hasn't been fixed yet, then if using this installer, or using Cas's manual install instructions, then if having something "special" installed which adds a dll used by gvsbuild to system32 folder, then these things can happen. I'm not even sure freezing actually fixes that, but I'm guessing it does, but just a guess though, and I don't have a clue about such, and wer're(well, you're, as I'm not using windows at all) waiting for doadin to hopefully get last few kinks ironed out, or Cas when he returns, and then an official installer could be made, or an unofficial in mean time, done just like the official, and not just using Cas's build instructions with extra patches and fixes on-top.

So rebuilding gvsbuild I doubt would fix it.

If I vagualy remember right, though honestly don't really, as cannot remember all the different reporters with there details, though I remember you e.g from #3201 ticket and here, e.g you helped me about reporting I included wrong openssl file by mistake once etc, but not your issue specifically and too lazy to go backtrack honestly now, but I guess I had you run dependency walker to gather log, as I usually do in these situations, but I couldn't see the issue, sorry, as not always easily spotible, atleast not for me. If wanna try building gvsbuild, then check doadin's github, as he has batch files for that. Also, the gvsbuild I use, is from Cas, from his manual instructions, which he forked on his github with some changes, e.g to packages wanted, I believe, and to use gtk 3.24 instead of default 3.22 etc.

I tried looking into building it also once, but had issues, because was meant for another compiler-suite, and not fully supported with mine ones and errors reported by others too concerning that, and I had 3 others installed, nearly 10gb in all(for initially getting both libtorrent stable versions to compile, though later found out how to patch something and use 2 different boost versions so only one compiler-suite needed, but regardless), and honestly didn't bother installing more, considering that seemingly isn't the issue.

Sorry again about not being able to help you out better.

[mhertz]

Paralel, I just checked your previous posts here, and you seem not to have reported this earlier, and it seemingly worked for you previously. Have you just somewhat recently had this issue and had it working beforehand? It seemed to work for you when this installer used 7z sfx as install-method(I'd presume from your wording in an older post where you recommended the installer to become official by the devs at one point), instead as now using NSIS, though the install-framework isn't the issue I'm confident in, but am just thinking what/when went wrong.

Normally when the issue is a mismatching picked up dll from system32, then the GTKUI will fail to start at all and not show a gtk window frame at all, so am little puzzled about that. It's one of the highly annoying things of windows(regarding this installer, though not a fan in general neither), that even though changing PATH to take precedence, then dlls from system32 folder, takes precedence from folder before that in PATH(just an issue with dll's and not exe's, but it's dll's in this case here concerning gtk3), so I have to find conflicting file with same name and need place in same folder for it to not mismatch, and I cannot have all gtk3 dll's in deluge main folder also, or only, as errors out then, and also sometimes shouldn't be in main deluge folder but in other subfolder of component calling the dll, e.g as I fixed when workaround'ing this issue with dll's of free-type etc. When using freezing which doesn't work fully currently though, then all files, including gtk ones and not only python ones, are locked down and contained by themselves, I believe, making this issue a non-issue, I atleast think, or guess. (Edit: As many other python apps have this issue too, with long bug-tickets on github, e.g numpy and anaconda etc, then I actually am not that sure anyway if freezing would help, as the issue is about non-python dlls and windows's annoying dll search path limitations e.g many apps do like me and place conflicting dlls in relevant folder from called component, also recommended by python devs as workaround I read.)

I always used same build of gvsbuild from Cas right from beginning to end, so never a change in that, regarding gtk3, as he never updated it further from initial build, though I did change out a couple of the extra components(called wheels in the python eco system, often consisting of pre-compiled C/C++ code and python mixed together, like as an example libtorrent.pyd etc, though I build my own of that/those specifically, e.g as the one of 1.1.x on pypi doesn't support https trackers) as needed py3.7 compatible versions and not the py3.6 versions Cas linked to from his manual install instructions.

I upgraded python to 3.7 from 3.6 and now 3.76 if remember right, but didn't made any drastic change from my tests and many others reporting OK.

Can you run the daemon fine and webUI and connect there from browser and/or deluge-console?

Also as test, try rename deluge profile folder to e.g 'deluge-bak' under '%appdata%' and rename back again afterwards.

I did read back in old thread from release of deluge 2.0 beta1, that one reported only being able to start thinclient and also issue connecting to localhost daemon there, I believe, and classic mode always failing.

Just for testing, did you try one of the other two libtorrents, e.g 1.1.x, as when only thinclient works, it's often a libtorrent issue, though built with same compiler, but differentiate anyway in one different patch used, and different boost version used.

[Paralel]

No, I never reported it, since it was just me mucking around with the latest build of GVSBuild and wondered if anyone else had attempted to do so as well and run into this error. I figured there was no point in reporting an attempt to work with an atypical GVSBuild. If it worked, great, but if it was a total mess, no big loss. However, what you said about multiple versions and relative priority totally makes sense. I'll have to try a clean environment and see if that makes a difference. I really need to remember to test in a clean environment (even better if its a clone) to limit variables.

[mhertz]

Gotcha, and sorry, I thought your issue with starting deluge was with this installer and then wanted to try a new gvsbuild to see if fixed it, hence I tried finding your original report, but misunderstood

If just replacing the gvsbuild folder with a newer build, then keep in mind I have e.g added msvc runtime files into that folder, so would need having this installed in windows or done again like me and copy relevant files needed into new gvsbuild dir. I'm not at my computer now, so am little unsure if I did anything else to that folder, I seem to recall I added one or a few other files there too, since that folder I made to be added to PATH at runtime and so might as well use it for something else needed, when already in search/lookup-path, and which didn't work from deluge main dir I believe. Maybe not, I honestly cannot remember as not done recently and in beginning of this installer back when it was in 7z sfx format. I do believe there was something though which I fixed in that way. BTW, it's only the bin folder somewhere under gvsbuild hierarchy I changed i.e adding runtime-files and possible one or a few more files needed. Anyway, you can compare Cas's gvsbuild folder with mine to see what was added into that bin folder and then copy over to your new built gvsbuild bin folder, or if having trouble then I can obtain the list of added files for you at later time.

[Paralel]

Sorry for not being clear regarding what I was talking about. I have an unfortunate tendency to do that. The additional information you provided should be very helpful in trying to get this working as I'm continuing to mess around with GVSBuild.