Using the move command, files are moved to the correct location, but savepath in Deluge is not upated

[roughwood]

Hello. I am really interested in using this plugin because it fits my needs perfectly, but I am running into a problem where when issueing a move command, the files are moved correctly to my movie folder, but deluge still has the "Save Path" as the old location, so seeding no longer works. It seems to be a little intermittent, as some torrents work correctly.

I'm not doing anything too out of the ordinary, the only thing I can think of that would be different than the standard setup is the default save location is a network drive Q:\download, and I have it trying to sort into Q:\Movies\Example (year).

More specifically, what happens is a torrent will finish, be set to paused, the file will be moved, and the save path is never updated and the torrent remains paused. This also occurs if I run the tool manually.

Any ideas or any other info I can provide?

[Laharah]

well, I do know that deluge doesn't recommend that you seed from network drives, but I'm not sure that would be enough to actually stop the move from happening.

One thing that may stop the move is that the file already exists, though the rename shouldn't have happened at all if that were the case.

During the rename, the torrent should pause, FilebotTool then waits for notifications that deluge has renamed and moved the storage and then it should resume the torrent. Does the torrent ever get resumed? If not, something is blocking one of the notifications. If it does resume, deluge is emiting the storage_moved event but not actually changing the storage location internally.

It's also possible that the save path was changed correctly, but it simply hasn't been updated in the client GUI. A restart of the deluge client should show the correct save path if that's the case. Can you give me some details about your setup? Are you running in classic interface mode, or in client/server mode?

If it happens again, you could try a "force recheck" on the torrent. If it really is messed up it should show 0% completed.

Also, if you could get the debug logs during a filebot rename that messes it up it would help me figure out what's going on internally. You can follow the instructions here to enable logging.

[roughwood]

Hello, thanks for the response. I'll add more detail as you requested:

Deluge version 1.3.13 Libtorrent version 1.0.9.0 Deluge classic interface.

Deluge is running on a PC dedicated to torrenting, with all the drives in my NAS machine mounted as network drives. When a movie torrent is added, the default save location is the network drive Q:\download. All of my sorted movies live in Q:\Movies.

Here is what my profile looks like:

After a torrent has finished downloading, here is a screenshot of what things look like:

I then right click the torrent, choose FilebotTool, select my profile, and press Execute. At this point the torrent is paused, the file is moved on the disk, but the torrent never resumes and deluge still shows the old path, as seen in the screenshot below:

If I now go to File > Exit to shutdown deluge, and reopen it, the torrent is shown as errored.

Also, if I do a "Force Recheck", the torrent shows 0.00%

Here is the log file that was generated while doing this: REDACTED

Lastly, I should point out that up until now I was moving and organizing my downloads manually by right clicking the torrent and selecting move storage, which always moved successfully and updated in Deluge.

Let me know if there is any other info I can provide!

[Laharah]

I've removed the link to your logs since they have some keys you wouldn't want public, But it seems that the relevant part is here:

[DEBUG ] 18:27:48 common:58 [FilebotTool] recieved results from filebot: (1, [(u'Q:\download\The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv', u'Q:\Movies\The Accountant (2016)\The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv')], []) [DEBUG ] 18:27:48 common:58 [FilebotTool] Attempting to re-reoute torrent: (u'Q:\Movies\The Accountant (2016)', None, [(0, u'The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv')]) [DEBUG ] 18:27:48 common:58 [FilebotTool] response from server: (True, None, []) [INFO ] 18:27:48 common:55 [FilebotTool] rename successful on ['1885a1751d54fe13e660effa61fb131b96f1492b'] [DEBUG ] 18:27:48 alertmanager:124 storage_moved_failed_alert: The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv storage move failed: The system cannot move the file to a different disk drive [DEBUG ] 18:27:48 alertmanager:124 file_renamed_alert: The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv: file 0 renamed to The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv [DEBUG ] 18:27:48 torrentmanager:1077 on_alert_storage_moved_failed: The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv storage move failed: The system cannot move the file to a different disk drive [ERROR ] 18:27:48 torrentmanager:1084 Torrent 1885a1751d54fe13e660effa61fb131b96f1492b, The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv storage move failed: The system cannot move the file to a different disk drive [DEBUG ] 18:27:48 torrentmanager:1164 on_alert_file_renamed [DEBUG ] 18:27:48 torrentmanager:1165 index: 0 name: The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv [DEBUG ] 18:27:48 rpcserver:467 intevents: {} [DEBUG ] 18:27:48 files_tab:645 index: 0 name: The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv [DEBUG ] 18:27:48 common:58 [FilebotTool] on_file_renamed(1885a1751d54fe13e660effa61fb131b96f1492b,0, The Accountant 2016 1080p BluRay DD5.1 x264-RightSiZE.mkv) [DEBUG ] 18:27:48 common:58 [FilebotTool] listning dictionary updated: {'1885a1751d54fe13e660effa61fb131b96f1492b': {'move_storage': u'Q:\Movies\The Accountant (2016)'}}

Looks like this is a problem in deluge itself. The torrent move here consists of 2 parts, a rename and a move storage. The rename goes through, but the storage move does not. Those on_alert_storage_moved_failed are the culprit. On windows, moving a file to a different disk involves a copying of data to the new disk, and then a deletion from the original disk. Those alerts seem to indicate that somewhere along the line, a rename is trying to move the file to another disk directly and failing.

A quick look through the deluge codebase shows that the call filebottool is making is being sent to libtorrent, which is then raising the storage move failed alerts. I'm not sure how or why your manual moves work though. According to the code, both filebottool and the deluge UI are making the same exact calls (namely torrent.move_storage(dest)), which means they should both be failing.

I'm fairly certain the problem is based in the fact that you're using network drives. You might try updating libtorrent if you can, since that's where the failure is coming from. I'll see if I can figure out why deluge's UI based calls are working, but filebottool's aren't, but since I can't replicate the problem I don't expect much luck.

It may be that libtorrent is throwing that error because it's being told to move a file that's already been moved by filebot. This usually works fine, at least it has on my windows and linux test setups, but the fact that it's on networked drives may be changing something. If you'd be willing to test something for me, could you pause a completed torrent, move the file using windows explorer, and then use deluge "move storage" to point it in the correct place? That should give a close facsimile to what filebottool is doing.

[roughwood]

I tried your suggestion of moving the file manually with windows explorer and then doing Move Storage to point at the new location, and interestingly enough this does not work. The save path remains the same and does not adjust to the new path.

I think you are right about this being a libtorrent issue, it seems that it does not want to overwrite files at all, or move to a directory where a file with the same name is present. I would think that when changing the save path to a directory with a file of the same name, the torrent would begin checking the file but it seems to just do nothing and fail instead.

I also have qBittorrent installed, and qBittorrent handles this situation properly. If a file is manually moved and then the storage path is updated, it goes through correctly from the new path. My installation of qBittorrent has a libtorrent version of 1.0.10.0 versus 1.0.9.0 in Deluge. I wonder if this is a result of the newer libtorrent version or if qBittorrent just handles this in a different fashion than Deluge.

Also, I tested this out on the local C drive of the torrenting PC and the same issue is occurring there, so I'm not sure network drives are the culprit.

[Laharah]

That's strange, since I do most of the coding and testing on a Windows machine, and this is the first I've seen of this problem. Indeed, the normal behavior I've seen is exactly how you described. Which version of Windows are you on?

I'll double check on my windows machine with a clean deluge install when I next get a chance. I doubt there's something installed that could be changing the normal behavior.

Did you install from deluge source, or from one of the installers on the deluge site?

[roughwood]

I installed it from from the 1.3.13-win32-py2.7-0.exe installer downloaded from the deluge website.

The PC is on Windows 10 Home version 1607 Build 14393.693

[Laharah]

yep, I can reproduce this bug on a new install of deluge. Not sure how I haven't come across it before. I'll search around for a fix and make a post about it on the deluge forums. Not sure how much it'll help as it's a problem in libtorrent, but maybe they'll have an idea of where to look.

This is a major bummer since the plugin depends on the correct behavior. There's no immediate fix that comes to mind that I can implement.

[roughwood]

Very interesting, I am at least glad that it is reproducible and not just me. Do you know of a version of Deluge that this is still working properly on in the meantime?

[Laharah]

a quick test shows that deluge 1.3.12 works correctly. I'd use the py 2.7 version, as it's the primary one I develop for.

[Laharah]

so it turns out that there are some new flags that I can pass to libtorrent to fix this. I've implemented a fix that works in all my tests. If you still have deluge 1.3.13 and you'd be willing to download the latest version and test it out I'd be grateful for the confirmation.