Bug: Torrents in unloadable state

General support for problems installing or using Deluge
Post Reply
link1468
New User
New User
Posts: 2
Joined: Fri Jul 16, 2021 9:37 pm

Bug: Torrents in unloadable state

Post by link1468 »

Issue:
Torrents that have not made an initial connection and downloaded their meta data are disappearing when rebooting deluge. The torrents are however listed in torrents.fastresume. The system will try to load them, but can't find their <HASH>.torrent file. When trying to re-add these torrents manually, the response is "deluge.error.AddTorrentError: Torrent already being added".

Steps to reproduce:
1. Limit concurrent downloads
2. Add more torrents than allowed concurrent downloads via API (Radarr, Sonarr etc.)
3. Restart deluge

Version: 2.0.4.dev56
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: Bug: Torrents in unloadable state

Post by mhertz »

Yes, I've played with this before, but couldn't fix it, and thought I had reported it, but see I haven't, so will do that, probably tomorrow or something.

The libtorrent spec stated will not save resume data if no metadata downloaded, so little strange. I messed with adding if clause for skipping if no metadata, but then stalled upon close so need play little more with it, though doubt I'm good enough to fix such but nonetheless.

I saw it wasent an issue on deluge1, and there these magnets are not saved in FastResume, so works upon restart - I always just tested with ipmagnet, as easiest, as fails download metadata. I couldn't really see why these diffs when checking save_resume_data() between deluge1 and deluge2, so maybe it's an libtorrent version change I don't know.

Workaround for now is manually deleting the FastResume file I found, which upon restart will restore everything, though should be done before starting deluge, as won't help after magnets actually gone.

I'll play with it little more tomorrow I think and if find anything I'll report back - I'll edit in the bugticket link also when having submitted it, if anyone should want follow it's progress.

Thanks for reminding me to look into this again, and if nothing else report it :)
link1468
New User
New User
Posts: 2
Joined: Fri Jul 16, 2021 9:37 pm

Re: Bug: Torrents in unloadable state

Post by link1468 »

Awesome, thanks for the workaround
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: Bug: Torrents in unloadable state

Post by mhertz »

You're welcome :) No luck yet unfortunetly, and need little more time before giving up and make said bug ticket.

Just slight info to add meanwhile - Of my testing so far, then deluge2 with libtorrent 1.1.x doesn't have this issue, so not a deluge2 problem as I initially suspected. With libtorrent 1.1.x then like api docs states, running its save_resume_data() function on a magnet without metadata doesn't save anything to its resume file, though does in 1.2.x. I grepped 1.2.x changelog for "metadata" and "resume" and learned behavior changed in libtorrent 1.2.11, hence our issue, so another workaround, though not very optimal, but nonetheless, should be to downgrade to libtorrent under 1.2.11.

The stall I had with my addition of a check for metadata in deluge resume_data function, I fixed by checking on its handle libtorrent object and not just own object, but problem is that now it returns metadata retrieved for some reason even when testing with magnet of non-existing info hash, so little at my witts end, but will keep testing little more, but as said will probably not lead to anything. Only thing working currently is fully disabling resuming of everything, which obviously isn't good.

Anyway just slight little status-update :)
mhertz
Moderator
Moderator
Posts: 2195
Joined: Wed Jan 22, 2014 5:05 am
Location: Denmark

Re: Bug: Torrents in unloadable state

Post by mhertz »

I finally got it fixed :)

I reported it on bug-tracker with included fix here:

https://dev.deluge-torrent.org/ticket/3478 (I prefer bug-tickets to PRs because never sure if devs find my fixes good enough)

Copy/pasting following into a terminal and pressing return, will apply said fix to wherever you have deluge installed on your setup, but please only do that if actually understanding the command run, as shouldn't really run commands found online otherwise, none the least where 'sudo' additionally is used.

Code: Select all

sudo find /usr -path */deluge/core/torrentmanager.py -exec sed -i '/t.handle.need/a\                if t.has_metadata' {} \;
Revert fix, just for "completeness":

Code: Select all

sudo find /usr -path *deluge/core/torrentmanager.py -exec sed -i '/t.has/d' {} \;
Alternatively, here's patch to apply, either directly through 'patch', or manually by reading it and apply change yourself:

deluge-magnet_fix.patch

Tested with multipe magnets and restarts on deluge-2.0.4.dev56 and libtorrent-1.2.14 on arch-linux, but should work everywhere, though as said previously, should only really be a problem if using libtorrent 1.2.11 and above. The issue can be reproduced yourself easilly with e.g. adding this "non-exisiting-infohash" magnet to deluge and restarting deluge, which will then "forget it" without fix: "magnet:?xt=urn:btih:85bbba4035cca750f681284857f53e405eb41f8d".

Thanks again for reporting this issue link1468, appreciated, as since said, had totally forgotten about this annoying and rather big issue myself.
Post Reply