rtorrent icon indicating copy to clipboard operation
rtorrent copied to clipboard

Magnet/DHT torrents refuse to work in rtorrent for me

Open haasn opened this issue 8 years ago • 22 comments

Reproduction steps:

  1. Start rtorrent
  2. Add magnet link of torrent that I know is popular. (I won't link any, but I'm sure you can find plenty on your own)
  3. Wait an hour
  4. Nothing happens, it's still only listed as the hash. The dht:// tracker is listed as 0f / 1s (0) on S/L/D: 0/0/0 (0/1 or something like that.

I have confirmed that:

  1. This is not a ports issue. I am connectable, both the DHT port and the rtorrent main port. Yes, I tested both TCP and UDP. I can tcpdump port <dht port> and see lots of UDP DHT traffic going both ways.
  2. This is not an issue with the torrent. I can add it to transmission or deluge and it starts downloading within a second in both, even before I open their ports! Only rtorrent fails.
  3. It fails working even if I extract the .torrent from one of the aforemention clients and add it directly to rtorrent (that is, with no additional trackers besides dht://).

Versions:

  • libtorrent 0.13.6
  • rtorrent 0.9.6
  • I am not using custom patches. I am not using libressl.

Configuration:

port_range = XXXXX-XXXXX
port_random = no
download_rate = 9000
upload_rate = 500

directory = ~/torrents
session = ~/.rtsession

use_udp_trackers = yes
encryption = allow_incoming, try_outgoing
dht = on
dht_port = YYYYY
peer_exchange = yes

Is there anything I can do, except “switch to deluge or transmission?”. Regular torrents work fine for me in rtorrent and I would not like to switch clients just for magnet links, if I can avoid it.

haasn avatar May 09 '17 01:05 haasn

Maybe because of this? Try it out without encryption.

# Encryption options (encryption), set to none (default) or any combination of the following: allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext
# The example value allows incoming encrypted connections, starts unencrypted outgoing connections but retries with encryption if they fail, preferring plaintext to RC4 encryption after the encrypted handshake
protocol.encryption.set = allow_incoming,prefer_plaintext,enable_retry

chros73 avatar May 09 '17 05:05 chros73

@chros73 Must be a different bug, because #61 indicates the issue going away when using encryption = allow_incoming, try_outgoing.

haasn avatar May 09 '17 05:05 haasn

I saw that but give it a try with the mentioned config entry anyway, it worked for me.

chros73 avatar May 09 '17 06:05 chros73

I have the same problems, and it definitely not the problems with encryptions. When i try 2 different magnet links: "lubuntu and arch" the arch magnet link work perpectly because it have upd/http tracker, on the other hand the lubuntu link stand there forever, the same problem happens with any torrent only use dht.

getmeacuboftea avatar Jun 05 '17 06:06 getmeacuboftea

Can you link/copy the magnet URI of lubuntu?

chros73 avatar Jun 05 '17 07:06 chros73

Yes, it here magnet:?xt=urn:btih:fb79819145731bd20a4570f73f335b534a99e0d2&dn=lubuntu-17.04-desktop-amd64.iso I was use it as reference link but it didn't show up, sorry.

getmeacuboftea avatar Jun 05 '17 07:06 getmeacuboftea

It works for me with current git version (rtorrent-ps-ch 1.5.0-0.9.7) and this config. The Magnet links for lubuntu are on this page. I used this one: magnet:?xt=urn:btih:fb79819145731bd20a4570f73f335b534a99e0d2&dn=lubuntu-17.04-desktop-amd64.iso

Note: I used this script to create a fake torrent file from Magnet link (although it shouldn't matter).

chros73 avatar Jun 05 '17 09:06 chros73

Thanks, i've try some other version or config but the same problems still happen. It's the "DHT search unsuccessful" problems describle in here https://github.com/rakshasa/rtorrent/wiki/Using-DHT. Seems like rtorrent need some port forward for the dht feature to work.

getmeacuboftea avatar Jun 06 '17 08:06 getmeacuboftea

Seems like rtorrent need some port forward for the dht feature to work.

It can be, just open dht_port as well.

chros73 avatar Jun 06 '17 10:06 chros73

Sorry to bring this up again, but after a while i saw that the number of peer in dht have no meaning, it always show 0/0/0 even when everything is working fine. And i can enable force encrypt in rtorrent with the help of aria2, it can convert magnet link to real torrent file so there's no need for a fake torrent file anymore. :). Also (in my case), i can confirm that you don't need to open dht_port, just open the torrent port is enough for dht, netstat didn't show the dht port as listening so i think it's obvious.

getmeacuboftea avatar Jun 20 '17 11:06 getmeacuboftea

And i can enable force encrypt in rtorrent with the help of aria2, it can convert magnet link to real torrent file so there's no need for a fake torrent file anymore. :).

Pretty good idea, thanks!

chros73 avatar Jun 20 '17 13:06 chros73

I am experiencing similar behavior using rtorrent version 0.9.6 on Ubuntu 16.04.3. I used the lubuntu magnet link chros37 posted. This one...

magnet:?xt=urn:btih:fb79819145731bd20a4570f73f335b534a99e0d2&dn=lubuntu-17.04-desktop-amd64.iso

DHT works and says...

Tracker[0:0]: Connecting to dht:// [Searching: 7/12 nodes replied]

Then this message goes away and the torrent just sits there and never downloads. There are no error messages in either the log file or in the rtorrent interface. My config has the following....

dht.mode.set = on
dht_port = 6881

schedule2 = dht_node_1, 5, 0, "dht.add_node=router.utorrent.com:6881"
schedule2 = dht_node_2, 5, 0, "dht.add_node=dht.transmissionbt.com:6881"
schedule2 = dht_node_3, 5, 0, "dht.add_node=router.bitcomet.com:6881"
schedule2 = dht_node_4, 5, 0, "dht.add_node=dht.aelitis.com:6881"

protocol.pex.set = yes 
trackers.use_udp.set = 1
encryption = allow_incoming,enable_retry,prefer_plaintext

Was anyone able to resolve this?

EDIT: Figured it out. The above settings were fine. I had to forward the rtorrents listening port. My port settings are...

network.port_range.set = 50000-50000 network.port_random.set = no

So I had to forward port 50000 on my router, I only had to forward that port for TCP. I did not have to forward port 6881.

necb77 avatar Jan 26 '18 17:01 necb77

One more thing. I have a VPN that I connect through. The port forwarding fix works fine when I'm not using my VPN, however, when I do use my VPN I'm back to the same problem because my VPN does not allow port forwarding. Is it safe to say I cannot use rtorrent through my VPN?

necb77 avatar Jan 26 '18 20:01 necb77

@necb77
Yes, rtorrent need open port for dht to work. It would be nice if someone can make a patch so you can turn on/off that requirement on demand.

getmeacuboftea avatar Jan 27 '18 01:01 getmeacuboftea

@getmeacuboftea Dang, sorry to hear that. It looks like rtorrent is not suitable for me.

necb77 avatar Jan 27 '18 02:01 necb77

Or choose a provider that supports port forwarding.

chros73 avatar Jan 27 '18 06:01 chros73

Hi. I have the similar issue (gentoo, rtorrent version 0.9.6):

# rtorrent -d /data/torrents -s ~/.config/rtorrent/session -o dht=on,dht_port=6881,dht.add_node=dht.transmissionbt.com
rtorrent: Failed to parse command line option: DHT not enabled.

I tried to define the same params via ~/.rtorrent.rc, but result the same: DHT not enabled

Without dht.add_node=dht.transmissionbt.com it starts successfully, but nothing happens.

rstrlcpy avatar Feb 01 '18 11:02 rstrlcpy

Take a look at this, maybe it helps.

chros73 avatar Feb 02 '18 11:02 chros73

Hi there, I was having the same problem, when using xmlrpc on python. Adding maglinks with label or with the download directory results in paused torrents that never start.

server = xmlrpclib.Server(server_url) result = server.load_start_verbose(maglink, "d.set_directory="+"""+downloadDir+""", "d.set_custom1="+"""+label+""")

If i just submit the link without any other parameter it begins to work. result = server.load_start_verbose(maglink).

CarlosMC avatar Jun 05 '18 13:06 CarlosMC

Sorry to bring this up again, but after a while i saw that the number of peer in dht have no meaning, it always show 0/0/0 even when everything is working fine. And i can enable force encrypt in rtorrent with the help of aria2, it can convert magnet link to real torrent file so there's no need for a fake torrent file anymore. :). Also (in my case), i can confirm that you don't need to open dht_port, just open the torrent port is enough for dht, netstat didn't show the dht port as listening so i think it's obvious.

Please, could you explain what and how you did this?

tserversbfs avatar Feb 03 '19 05:02 tserversbfs

could you explain what and how you did this?

Something similar like this.

chros73 avatar Feb 03 '19 09:02 chros73

This has suddenly started happening to me today. I've got no idea why. It was working before but now it reporting all magnets as suddenly not working.

Martyn575 avatar Nov 05 '24 22:11 Martyn575

Fixed.

rakshasa avatar Aug 27 '25 09:08 rakshasa

Fixed.

Hello, I've compiled the latest version of rtorrent/librtorrent from source and I still can't start magnet links. I have a VPN that does not allow port forwarding, but according to the wiki, I should still be able to start them. They work in other clients such as qbittorrent.

ref: https://github.com/rakshasa/rtorrent/wiki/Common-Tasks-in-rTorrent#supporting-public-torrents-magnet-links-udp-trackers-dht

• TCP/UDP port for tracker communication: DHT requires open/forwarded port(s) to work with this/these port(s)! • UDP port for DHT (DHT does not require open/forwarded port to work with this port)

billbeans avatar Nov 06 '25 02:11 billbeans

Make sure you are using 0.16.2 and check the dht_all and tracker_requests logs.

rakshasa avatar Nov 06 '25 08:11 rakshasa

I compiled 0.16.2 and now the program is terminating after about a minute with this message:

terminate called after throwing an instance of 'torrent::internal_error'                           
                                                                          what():  Poll::modify(...) epoll_ctl(9, 3 -> 3, 686, [0x7f599c6f1ab0:8]) = 9: Bad file descriptor
                    Aborted

I'm not sure if I did something wrong with the manual install or if this is a new bug. I installed libtorrent to ~/.local of which lib is in my LD_LIBRARY_PATH and the actual rtorrent binary resides in my home bin.

billbeans avatar Nov 14 '25 21:11 billbeans

Try latest master branch.

rakshasa avatar Nov 15 '25 08:11 rakshasa