Deluge Forum

I'm sorry if I'm being an ass, but this thread is already 36 pages long and nobody will read it from start to finish to know whats happening. Could you please just let me know if this unofficial installer is working? If not, how should I proceed?

Lol, yeah sorry, I of course get that, but I instead make a habit out of editing first post with whatever important info there is, or delete outdated info e.g I edited that post over 100 times now the board states. However I get of-course that people not necessarily know that, so I'll edit said post again and add a note about that i.e no need to read whole thread to catch up, as first post is kept up to date with relevant info, so thanks for raising a very good point (Edit: Done.)

There shouldn't be an issue as far as I know, but do like first post suggest and backup your deluge profile just in case, and also uninstall old deluge1 first if having that installed currently. Old torrents from deluge1, possibly only show up automatically in deluge2 if using the dev installer, but if no non-ASCII chars in torrents, then stable deluge2 also should work for that. Lastly, if getting tracker errors and/or connectivity issues in general, then reinstall while selecting libtorrent 1.2.3, or 1.1.x instead of default 1.2.x, as one reported still unresolved issues, which previously was an issue for certain specific network setups with latest libtorrent, though I never experienced it myself. Again, all mentioned in first post.

Note, of course I can't tell you if deluge2 will work for you fine in general, e.g one reported whenever adding a torrent, then deluge crashed, but that also could happen on deluge1 I saw reported online, but generally it should work, and there's no issues for me on clean win10 VM's and several others reporting success here. That's why you should backup your profile first, so you can if issues appear, go back to deluge1 again and have everything the same as before, so no risk in trying this out then.

I built latest gtk3 released 6 days ago(3.24.16) and latest libtorrent 1.2.x, plus updated to latest openssl 1.1.1f and built/uploaded new installers, so now every component in these installers to best of my knowledge is latest version.

I made a ticket on gvsbuild's github and asked for help, because my changes to gvsbuild to build newest gtk3 failed with some errors I knew nothing about, and googling it didn't help and no other tickets regarding this neither. Luckily I got help from a dev with some clues that let me find a solution. I got explained from my posted error-log that the error lines where related to some failing commands only available on linux(gcc) and not windows(msvc), so there seemingly where added a few of those unsupported for windows commands to newest gtk3. So I wen't to gtk3's github to look for the commits for said added failing commands so as to generate a patch to revert them, but didn't need to, since found two new commits just released which reverted those commands already, and so I made two patches from the two commits and added them to gvsbuild's build-system and updated a control-file with the patches to apply and it finally worked, so I posted a patch to my ticket to fix these issues and add the missing patches to gvsbuild to others in trouble wth this also.

mhertz wrote:... Old torrents from deluge1, possibly only show up automatically in deluge2 if using the dev installer, but if no non-ASCII chars in torrents, then stable deluge2 also should work for that.
...

Hi mhertz

Just wanted to note that I had some issues with non-ASCII character torrents and Deluge 2.0.3. They wouldn't import from 1.2 and I wasn't able to add them manually into 2.0.3. It worked just fine with 2.0.4-dev23, so I would recommend this version if one has any non-ASCII torrents.

Bug tracker: https://dev.deluge-torrent.org/ticket/3298

Cheers

Thank you fmar, appreciate your post, and I wasen't aware there also where issues with manually adding them too, so good recommendation there indeed

I have thought about backporting that commit into the stable deluge 2.0.3 many times, especially as I already have backported two other commits, one where the upload/download speed/amount where misplaced and a fix for failing generating PID, which was usefull to add because of something I cannot remember now, maybe to shut up an error or something, was long ago really. Anyway, I was just thinking that if I backport this and that, then it will not be stable deluge 2.0.3 anymore really. Granted the fixes are fully stable i'm relativelly sure, but still, a release is a release, and tagged for a reason. Though I already wen't "over the line" and fixed the wrong displaying, since got reported several times, and no need to keep repeat with copy/paste how to manually fix or patch it, and the PID fix which was needed for something else, so one more fix wouldn't hurt or mean anything, as already not 2.0.3 anymore if we are totally going by the definition of versioning, so even though it's a very useful commit, probably the most usefull of all in the dev release, then I have been on the fence about it, but as you stated then it would be best to simply use the dev release. However, i'm thinking maybe some private trackers have some rules for allowed versions, and not accepting e.g. dev or beta releases, and also for people not liking using anything but stable releases in general and hence why I'm building and providing two separate releases. Granted you can use ltconfig to change clientid, but you're probably breaking the rules then of said private tracker and risk banning if found out.

Sorry didn't ment to write a whole essay about that, lol Thanks again!

You're right about the versioning issue, it's not very consistent though not too worrying.
Maybe just backport the ASCII fix and rename your build to 2.0.3-1, 2.0.3-beta or 2.0.3-mhertz? Not sure if that gets in conflict with the official versioning.

As for the ASCII character bug and upgrading: it should be possible to use the 2.0.4 dev build to upgrade all the torrents and then downgrade to the official 2.0.3 release. But I haven't testet that yet.

As for private trackers, I couldn't really say nor would I really know, but it looks like that some of them whitelist any Deluge 2.* client, including development version.

Yes, that is indeed a possibility, though I'm not really sure about what I wanna do honestly, I'm actually thinking about reverting the two backported commits and just state to use dev if having issues. Although I seem to remember the one fix for PID creation was useful for something important, like starting the daemon of localhost from config manager, but have to go back and see why I did it in first place. Hmm, come to think of it, I now remember also adding a patch from Cas to both installers for getting GeoIP to work as needed as had stopped working, and a code change and another python package added which Cas stated in a reply to bug ticket about it. I did this by request, and because fixed a non-working function of deluge. There's several more fixes too, just not backported from develop branch and so added to both installers, which I too forgot take into equation , so for now will just let it be honestly I think, and I also stated I wouldn't mess around more with these installers, as probably not long until official release emerges anyway, though I really wanted newest gtk3 included and not old version, but we don't know how long anyway until the official release comes, and I honestly have a hard time not messing around with this little project from time to time, and just said such because I thought the official release was just around the corner, but we don't know that of course, and still doesn't hurt messing little around with this, even though won't be useful when official release comes.

Come to think about it, then many distros also add a **** load of patches for reported issues in there stable versioned releases. Though some state added git commits in addition to the release version in filename, but not all, and would be hard when a distro adds 4-5 or more patches, so maybe I'm just overthinking this, and not such a big deal anyway. Hmm, they then do what you suggested and add an internal version number additionally which does make sense. Actually that's always done I guess, no matter if patches added, atleast on arch-linux.

Your idea of installing dev for getting old torrents and then installing stable, was pretty smart thinking there, I'm sure it would work cannot see why not.

Tobbez also previously posted some python code to fix the old torrents getting through, but needs run from your deluge profile folder, or adding path to state, and have python installed obviously, or using deluge' s python, but I was thinking of making a little tool in exe format, just a 7z-sfx I think, that would do it when run, with embedded python and tobbez's script and some scripting on-top, e.g letting you select profile dir and then patch the state file from there, or simply assume it is under %appdata%/deluge, and not running with e.g several instances using different profiles or whatnot, but haven't looked into it yet. Ohh, I could add that python script to be run automatically at end of stable install, though then run every time you upgrade, though wouldn't hurt in reality. Hmm, I could add yet another checkbox under optional components during stable install, for running this code. That would be cool imho. So many ideers but no time to fulfill 'em all, lol

About blacklisted dev versions on private trackers, then I dunno but just remember some stating they couldn't use the beta Cas released some time ago because of that, but don't know how prevailant such is.

Thanks for bringing some good ideers to the table, appreciated mate

Edit: Upon further thought, much easier to simply backport said commit from develop branch and into 2.0.3, as important fix missing, so will do that when having time/motivation, maybe tomorrow, or day after at latest, I'm thinking atleast.

FYI: I just downgraded my 2.0.4-dev23 installation to 2.0.3 without any hickups or issues (I'm using libtorrent 1.2.5).
So this could be a good alternative for someone wanting to run the release build.

Thanks again fmar for testing/reporting, appreciated mate!

@all, I just saw gtk3 released a new release today(3.24.17), so most likely I'll build that tomorrow if no hickups, plus as before mentioned, backport the develop branch's torrent-importing-fix to the stable 2.0.3 release and build/upload new installers.

I'll post again when done.

New installers up now with latest gtk 3.24.17, and backported commit from development branch added to stable deluge-2.0.3 installer to fix importing old torrents from deluge1, though I changed the commit a little because some lines weren't needed in my installers and I omitted importing an additional module also not needed here neither + the test-cases too were irrelevant for us. It wouldn't hurt though to include of-course(the stuff I omitted), but why add superfluous stuff I'm always thinking. I edited first post to delete the part about the dev installer was recommended if needing that(importing old torrents from deluge1), as they're equal now regarding that.

Note, if just having upgraded with previous rebuild, then not really important to update to this here, as the backported commit for stable installer only is useful for initial install during the change from deluge1 to deluge2 and the gtk3 release from yesterday didn't have many changes regarding our usage here, and the ones added weren't really that important neither, so up to you. I just wanted latest version included regardless and generally only will omit an update if there's no related to us changes at all whatsoever.

(Also, I regardless wanted to build this gtk3 release so as to report back to my ticket on gvsbuild's github, that the extra additional previous patches I posted, wasent needed anymore in this newest release, and post new patch for changing gvsbuild to use this latest gtk3 version now.)