idlesign / deluge-webapi

Plugin for Deluge WebUI providing sane JSON API
https://github.com/idlesign/deluge-webapi
BSD 3-Clause "New" or "Revised" License
120 stars 28 forks source link

The add_torrent method is not adding torrent #26

Open Riiskyy opened 5 years ago

Riiskyy commented 5 years ago

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 commented 5 years ago

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}

idlesign commented 5 years ago

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.

Riiskyy commented 5 years ago

The python test script passes:

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

idlesign commented 5 years ago

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

Riiskyy commented 5 years ago

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.

idlesign commented 5 years ago

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.

Riiskyy commented 5 years ago

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.
idlesign commented 5 years ago

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.

Riiskyy commented 5 years ago

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.