deluge-webapi icon indicating copy to clipboard operation
deluge-webapi copied to clipboard

The add_torrent method is not adding torrent

Open Riiskyy opened this issue 4 years ago • 9 comments

Hi,

Using the add_torrent method I get a response from the api, however the result and error fields are blank and the torrent is not added. You'll have to bear with me as I'm using powershell for this.

Payload:

{
    "id":  1,
    "method":  "webapi.add_torrent",
    "params":  [
                   "magnet_link",
                   {
                       "download_location":  "/home1/riiskyy/ftproot/"
                   }
               ]
}

I then run the following command to add the magnet link to the webui: Invoke-RestMethod $DelugeApi -WebSession $session -Body $JsonQuery -Method Post -ContentType 'application/json'

The output returned from this is as follows:

id result error
-- ------ -----
 1

If I call the check_session method I can see I'm still authenticated:

$ConnectionCheck = [ordered]@{
            id     = 1
            method = 'auth.check_session'
            params = @()
        }

PS C:\Users\Administrator> Invoke-RestMethod $DelugeApi -WebSession $session -Body ($ConnectionCheck | ConvertTo-Json) -Method Post -ContentType 'application/json'

id result error
-- ------ -----
 1   True

I'm not sure if it's an issue with the magnet link that would cause this or if it is something else?

Riiskyy avatar Oct 17 '19 14:10 Riiskyy

I checked my message through fiddler and I'm still not sure what is wrong: Headers from fiddler:

POST /deluge/json HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-GB) WindowsPowerShell/5.1.18362.145
Content-Type: application/json
Host: xxxxxxxxxxxxxxxxxxxxxxxx
Cookie: _session_id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Length: 651

Body:

{
    "id":  1,
    "method":  "webapi.add_torrent",
    "params":  [
                   "https://magnet_link.fake",
                   {
                       "download_location":  "/home1/riiskyy/ftproot/"
                   }
               ]
}

Response: {"id": 1, "result": null, "error": null}

Riiskyy avatar Oct 17 '19 21:10 Riiskyy

Hi,

First of all please verify that https://github.com/idlesign/deluge-webapi/blob/master/webapi/test.py is passing, that'd help you to make sure that configuration is proper.

idlesign avatar Oct 18 '19 04:10 idlesign

The python test script passes:

================== RESTART: C:/Users/riiskyy/Desktop/test.py ================== WebAPI version: 0.3.2 Success

Riiskyy avatar Oct 18 '19 07:10 Riiskyy

Ok, you may try to use the latest version or take a note on passing the args, as it's done here: https://github.com/idlesign/torrt/blob/master/torrt/rpc/deluge.py#L94

idlesign avatar Oct 18 '19 08:10 idlesign

I cannot use 0.4.0 because the version of deluge that I am running is not compatible (I had already tried installing those .egg files). And that link is what I used to make sure my json payload was properly formated and I was passing the parameters correctly. The output from that function gives me

{
    "id": 1,
    "method": "webapi.add_torrent",
    "params": [
        "https://magnet_link.fake",
        {"download_location": "/home1/riiskyy/ftproot"}
        ]
}

Which, as you can see from my output from fiddler, is the same as the payload I am sending through my own application. Yet I still get no errors, but nothing added to deluge.

I also double checked the magnet link I am sending in the payload and if I manually add the magnet link to deluge it is recognised and added to the download queue.

Riiskyy avatar Oct 18 '19 10:10 Riiskyy

I see. In such cases it's best to run deluge in DEBUG mode and see logs to clear things up.

My guess is: magnets expected by Deluge are magnet:?xt=urn:btih:, not https.

idlesign avatar Oct 21 '19 04:10 idlesign

So I've tried out some more things that will hopefully help find the issue. Firstly maybe some context will help.

I am using Jackett as an indexer for my sites. Jackett generates and xml 'torznab' feed which is where I am pulling information about my torrents (including the download url which will be in the format https://<host>/jackett/dl/<indexer>/?jackett_apikey=<key>$path=<encoded>&file=<filename>. When this URL is added to deluge manually through the webui, the torrent is recognised, the file information is pulled, and I am able to start downloading.

The above method is also how Sonarr adds torrents to deluge, except instead of using a webapi.add_torrents method, it uses a core.add_torrent_magnet or core.add_torrent_file method.

After going over my deluge logs I found that when I try and add a torrent I get the following error in the logs:

Unable to decode torrent file!: unexpected end of file in bencoded string

As you suggested that it could be expecting the magnet:?xt=urn:btih: denotion, I thought I would try an alternative method of adding the torrent. This time I tried

  1. Downloading the torrent file
  2. Importing the base64 library in to IDLE and then running the file through the base64encode method in the repo you referenced.

Step 2 gave me the following string QzpcVXNlcnNcdGd3dzFcRGVza3RvcFxQb2tlbW9uXCBMZXRzXCBHb1wgRWV2ZWVcIFVwZGF0ZVwg\ndjFcIDBcIDFcIE5TVy1WRU5PTS50b3JyZW50\n, I then used the build_request_payload function to build the JSON with this data instead which gave me '{"id": 1, "method": "webapi.add_torrent", "params": ["QzpcVXNlcnNcdGd3dzFcRGVza3RvcFxQb2tlbW9uXCBMZXRzXCBHb1wgRWV2ZWVcIFVwZGF0ZVwg\\ndjFcIDBcIDFcIE5TVy1WRU5PTS50b3JyZW50\\n", {"download_location": "/home1/riiskyyy/downloads/"}]}'.

However even after this, the torrent was still not added to deluge, I tried using the same core.add_torrent_magnet & core.add_torrent_file methods (the methods that sonarr uses), with the link and the decoded file respectivley, but still the same result no error but nothing added to deluge.

When I looked back over my deluge logs, the times I had tried to add the file using the decoded utf-8 output of the torrent file I had different errors:

There was an error decoding the filedump string!
Incorrect padding
Traceback (most recent call last):
  File "/opt/deluge-1.3.15/local/lib/python2.7/site-packages/deluge-1.3.15-py2.7.egg/deluge/core/core.py", line 249, in add_torrent_file
    filedump = base64.decodestring(filedump)
  File "/usr/lib/python2.7/base64.py", line 328, in decodestring
    return binascii.a2b_base64(s)
Error: Incorrect padding

Once I removed the \n from the decoded string it just went back to the Unable to decode torrent file!: unexpected end of file in bencoded string error.

I have also tired without adding a path for where to download the torrent to so it would just use the default set in deluge. But this also did not work.

I'm not sure what the issue is here as the following are all true:

  1. Sonarr can add torrents to deluge using the Jackett download link, but I cannot using JSON.
  2. I can add the torrent using the same URL manually through the web ui.
  3. If I manually download the file and decode it with the base64decode function it does not work.
  4. The deluge core.add_torrent_magnet and core.add_torrent_file method produce the same results as 1 & 3.

Riiskyy avatar Oct 21 '19 09:10 Riiskyy

I suspect that Deluge automatically fetches contents from your https://... (which is a .torrent file, I guess) and processes it.

So your option would be to download the .torrent manually (e.g. using requests) and give to webapi. Or you may use, say https://github.com/idlesign/torrentool and generate a magnet for that .torrent and feed that magnet to webapi.

You may also make webapi better and extend add_torrent https://github.com/idlesign/deluge-webapi/blob/master/webapi/webui.py#L62 so that if metadata starts with http:// or https://, core.add_torrent_url() is used.

idlesign avatar Oct 21 '19 10:10 idlesign

Hmm, maybe. I will have to do some digging as the deluge client is hosted on a server that I do not have root access to and my calls to the deluge-api are coming from a slack bot coded using PowerShell.

My knowledge of python allows me to sumble my way through reading it and running some basic stuff, but probably not enough to write a fix.

Riiskyy avatar Oct 21 '19 11:10 Riiskyy