Deluge Forum

ssclanker wrote:Anyone else having problems with labelplus not applying the "move completed" option to the autolabeled torrents? I have an autolabel set up that works flawlessly, it matches torrents when I add them and applies the proper download directory but for some reason it does not apply the proper move on completed directory. The weirdest part is that right now, when I just added a torrrent, looking at the GTKUI I can see that the path name that I have set in the autolabeler to move on completed is there, but the move on completed option is not enabled.

I am using Deluge 1.3.15 and the only other plugins I am using is Movetools and the default label plugin.

I'm seeing this same thing. I even migrated to Deluge 2.0.3 and still it seems that move completed only works a fraction of the time. I really don't understand why this isn't working reliably.

I tried mgaulton's latest fork https://github.com/mgaulton/deluge-labelplus, but I am still experiencing this issue where files are not being automatically moved unless I set the LabelPlus label again or trigger a force move files (movetools).

Strangely, it works for some labels, but not others, and I cannot find a common denominator and there are no errors reported in logs.

Sorry, I don't know, but quickly tested bdutro's latest fork, and it failed in my two tests, one for move_completed and one for changing download_location initially, both with a magnet download and autolabel set to match '.iso' ending of any contained file, which worked last time I tested that, a year maybe ago or so. Tested using deluge 2.0.4-dev38 / libtorrent 1.2.9, on arch-linux. Anyway, I wanted to report the error displayed from debug-log, but sadly both bdutro and the other newer fork I just learned about from mgaulton(I don't think his latest change(s) are relevant here, though could be wrong of-course), doesn't have any issues sections enabled on there github's, only PRs, and I have no solution unfortunetly, so not of much help sadly

Okay, thanks for confirming this bug. Yeah, those exceptions don't make too much sense to me either. I might have to make an Execute script as a work around for this to attempt to apply the labelplus label another way..unless you can think of anything else.

I'll try tomorrow to downgrade libtorrent and use deluge 2.0.3, and retest, as that was only change since last working config, I believe, as the bdutro fork wasent updated either, from last time.

Thanks for letting us know about the newer mgaulton fork btw

I'll post the bug-report tomorrow, in bdutro's unmerged PR of ratanak's original repo, which I just came to think about, and previously used for another previous issue, which bdutro fixed(magnet autolabel support).

Beautiful. Thanks for help pushing this forward.

In the interim, I will try to find some manner of a work around for this issue. This was also something I was experiencing before I upgraded to v2.

On my end, I get this fixed by reverting to libtorrent 1.2.8, instead of 1.2.9, as only change, still using deluge 2.0.4-dev38 on arch-linux. Both test scenarious I ran before with move_storage and download-location-change, worked now with reverting libtorrent versions, both tests done several times to make sure, and with reverting back to newest libtorrent again, then again fails every time, in several consecutive tests of both scenarious.

I'm not sure this is the exact issue you or the other reporters are having, as some reports came out before libtorrent 1.2.9 was released, plus few use the very newest versions also, and lastly, since it reportingly comes intermittently, or only on some labels, whereas for me it's everytime, atleast for the tests i've done with it.

Anyway, here's nonetheless the report to bdutro in his PR thread to ratanalvlun's original labelplus repo:
https://github.com/ratanakvlun/deluge-labelplus/pull/37

@skupjoe and others having the before mentioned issue,

As I said before, I doubt my issue mentioned above, was the same issue as you guys, and also now after discovering that qbittorrent-nox(and regular qbittorrent) won't even start with libtorrent 1.2.9 and states on terminal:

"qbittorrent-nox: symbol lookup error: qbittorrent-nox: undefined symbol: _ZNK10libtorrent5entry4dictB5cxx11Ev".

Googling the above error, was once reported some months ago, where the qbittorrent lead-dev stated he had build libtorrent with deprecated functions disabled and would rebuild to fix, but checking my distro's PKGBUILD (control file) for libtorrent, then there where no changes in the building and just an updated source tarball link and sha1 hash, but there is some changes that probably is the culprit in libtorrent 1.2.9 changelog itself, but anyway, I post this because bdutro enabled an issues section on his github fork repo now, and asked that I opened a ticket there to go foreward, but as said, I don't wanna waste his time with something irrelevant.

Edit: Yes, this issue is seperate, as just tested regular move_complete in deluge, without labelplus, and the same issue happens, with no move happening on libtorrent 1.2.9 and same error.

Edit2: PR in progress for this on libtorrent github + reportedly working fix included in gentoo ebuild:

Thanks for creating and maintaining this great plug-in. As I configured my setup with this I found some bugs and crucial suggestions I feel need addressing.

1. For sub-folders inside main folders, there seems to be incomplete hierarchical inheritance. When the "Downloads" tab are set inside the "Label Options" window they are passed on from the main folder to sub-folder. However, the options set in the "Autolabel" tab seem to be ignored. For example, I'd prefer to set the main folder as "books" and configure the respective autolabel tab options to match it. But, when the "books" folder has a subfolder named "sci-fi" with the respective autolabel tab options set I would prefer for it to inherit the main folder (books/scifi). Instead, the two autolabel options set within a folder and subfolder seem to compete and conflict with each other and either books or books/scifi end up being set rather than to inherit its hierarchical order. I repeat, subfolders do inherit settings from the "Downloads" tab but not the "Autolabel" tab. I suggest a clear hierarchical inheritance option to be user selectable as true or false. This might not be the way LabelPlus was designed, but it would things much more clearer and flexible . At first I had to learn how this Plugin did not work for me to properly know how it did work to set things up.

2. When the setting "Move Completed" is enabled and configured under the "Downloads" tab in the "Label Options" window it ignores requests when you change the directory inside the "Statusbar" pane under the "Options" tab in the "Move completed" field. I change the directory in "Move completed" field, click "Apply" and it does not move the already downloaded torrent. However, it does work if I right click on the torrent to select "Move Downloaded Folder" then change the directory and click ok. This seems to a conflict of how Deluge works versus LabelPlus.

3. Being able to input Regex made me switch from my old torrent client to Deluge and use LabelPlus, so thank you immensely. In the Autolabel tab there is a conflicting option. When I select the "match regex" option from the drop down and then insert the respective regex which equates to 'does not match' it simply does not work. I've tried inserting various regex code to accomplish 'does not match' such as ^((?!STRING).)*$ and various other code containing negative lookahead (?!…) and negative lookbehind (?<!…) to no success.

Just wanted to add that labelplus works correctly for me with bdutro's fork with latest 1.2.x libtorrent i.e 1.2.13, so move_complete works in labelplus, and deluge itself, which was a previous issue also. I haven't tested this issue since 1.2.9 which failed, so maybe was fixed long ago, dunno. Probably should have tested with mgaulton's fork instead, as little newer(3 extra commits), but regardless(Edit: Checked those extra commits and are specifically related to labelplus+label plugin users, where labelplus label added to label's label when labelplus label not matching label's label). As always, rename plugin filename to match installed python 3 version if unavailable for download, e.g I renamed in my case bdutro's latest: LabelPlus-0.3.2.4-py3.8.egg to 'LabelPlus-0.3.2.4-py3.9.egg' and restart deluge to enable. Python version found with 'python --version' or 'python3 --version' and should show 'python 3.x.x' and only rename to one decimal after dot i.e I had 3.9.2 python 3 installed.