rTorrent + Rutorrent Upload issues.

saroos1

Member
May 25, 2018
718
0
16
Atm I'm having issues with getting uploads to work at all. I'm thinking this probably is a rtorrent issue, but as I'm completely stuck and i believe this combo could shine if set up properly I'm hoping someone here would be kind and help me out

The torrents I'm fetching via RSS are high activity torrents and if i fetch one to my local computer it instantly picks up actively seeding the data and building ratio fairly fast.

on the seedbox, nothing.

So far i've checked port config

Canyouseeme.org responds: Success: I can see your service on <IP> on port (64499)
Your ISP is not blocking port 64499

Downloading torrents is also fast (get around 5mb/sec down)

Atm Rutorrent displays:


rtorrent config:
Code
#This s is an example resource file for rTorrent. Copy to
# ~/.rtorrent.rc and enable/modify the options as needed. Remember to
# uncomment the options you wish to enable.

# Global
max_downloads_global = 10
max_uploads_global = 100

# Maximum and minimum number of peers to connect to per torrent.
min_peers = 20
max_peers = 200

# Same as above but for seeding completed torrents (-1 = same as downloading)
min_peers_seed = 20
max_peers_seed = 250

# Maximum number of simultanious uploads per torrent.
max_uploads = 20

# Global upload and download rate in KiB. "0" for unlimited.
download_rate = 0
upload_rate = 0

# Default directory to save the downloaded torrents.
directory = ~/GroundZero/Internal/Downloads

# Default session directory. Make sure you don't run multiple instance
# of rtorrent using the same session directory. Perhaps using a
# relative path?
session = ~/.session

# Watch a directory for new torrents, and stop those that have been
# deleted.
schedule = watch_directory,5,5,load_start=~/rtorrent/torrents/*.torrent
#schedule = untied_directory,5,5,stop_untied=

# Close torrents when diskspace is low.
#schedule = low_diskspace,5,60,close_low_diskspace=500M

# Stop torrents when reaching upload ratio in percent,
# when also reaching total upload in bytes, or when
# reaching final upload ratio in percent.
# example: stop at ratio 2.0 with at least 200 MB uploaded, or else ratio 20.0
#schedule = ratio,60,60,stop_on_ratio=200,200M,2000

# The ip address reported to the tracker.
#ip = 127.0.0.1
#ip = rakshasa.no
# Port range to use for listening.
port_range = 64300-64500

scgi_port = 127.0.0.1:5000

# Start opening ports at a random position within the port range.
port_random = yes

# Check hash for finished torrents. Might be usefull until the bug is
# fixed that causes lack of diskspace not to be properly reported.
check_hash = no

# Set whetever the client should try to connect to UDP trackers.
use_udp_trackers = no

# Alternative calls to bind and ip that should handle dynamic ip's.
#schedule = ip_tick,0,1800,ip=rakshasa
#schedule = bind_tick,0,1800,bind=rakshasa

# Encryption options, 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
#
encryption = allow_incoming,enable_retry,prefer_plaintext
# encryption = allow_incoming,try_outgoing

# On completed DL Update xbmc library
system.method.set_key =event.download.finished,Update_Library,"execute=/home/kvg/.xbmc/updatelib.sh"

execute = {sh,-c,/usr/bin/php /var/www/rutorrent/php/initplugins.php kvg &}


#
# Do not modify the following parameters unless you know what you're doing.
#

# Hash read-ahead controls how many MB to request the kernel to read
# ahead. If the value is too low the disk may not be fully utilized,
# while if too high the kernel might not be able to keep the read
# pages in memory thus end up trashing.
hash_read_ahead = 10
# Interval between attempts to check the hash, in milliseconds.
hash_interval = 10

# Number of attempts to check the hash while using the mincore status,
# before forcing. Overworked systems might need lower values to get a
# decent hash checking rate.
hash_max_tries = 5

# Max number of files to keep open simultaniously.
max_open_files = 256

# Number of sockets to simultaneously keep open.
#max_open_sockets = <no default>

max_open_http = 24

# Example of scheduling commands: Switch between two ip's every 5
# seconds.
#schedule = "ip_tick1,5,10,ip=torretta"
#schedule = "ip_tick2,10,10,ip=lampedusa"

# Remove a scheduled event.
#schedule_remove = "ip_tick1"

dht = disable

peer_exchange = no

preload_type = 1

max_memory_usage = 1024M
 

peshua19

Member
May 25, 2018
897
0
16
Quote
port_range = 64300-64500
port_random = yes​

This means - each time, when rtorrent is started, it will use a random port from interval 64300-64500. As result, this -
Quote
Canyouseeme.org responds: Success: I can see your service on <IP> on port (64499)
Your ISP is not blocking port 64499​

may hasn't relation to port, which rtorrent really use at the current moment.
 

saroos1

Member
May 25, 2018
718
0
16
sorry, the rTorrent UI claimed that it was running on that port so i checked it. Means that i think there aren't any issues with the port forwarding?
 

saroos1

Member
May 25, 2018
718
0
16
Ok, a bit of an update:

I tried seeding ubuntu and that, being a public torrent started seeding at almost acceptable speeds. My first line of thought here was simply that the private trackers for some strange reason weren't generating any traffic to my torrents.

To test this i took down one of the seeded torrents from the seedbox (that after 4 hours of seeding still was at 0.000 ratio) and started the seeding up from my uTorrent client on my desktop. After 1 hour and 22 minutes this seed is up to 0.340 ratio.

Clearly there is something wrong with rtorrent and all the private trackers.
 

randac56

Member
May 25, 2018
915
0
16
i think it could also be that your torrents just dont' have any peers on your node.

it happens. just because a tracker says there are 10..20...30 leechers doesn't mean you will connect to them. how are you adding these torrents?

if you are just picking them and adding them yourself, manually, chances are they just dont' have anyone downloading them.


if you are using RSS, then it MIGHT be something i'd worry about.
 

simur612

Member
May 25, 2018
879
0
16
1. As i said I'm fetching the torrents via RSS

2. I was worried that what you said might be right, so i tried 2 or 3 times now with different torrents to just restart the torrent from my desktop computer instead of my server (meaning pausing the rtorrent torrent, downloading the .torrent, setting it up against the server with the smb share path and starting it locally in uTorrent) the torrents repeatedly connect to peers and have pushed their ratios up to at least 0.5 within 2 hours of adding them while the non-paused torrents on the ubuntu box mainly idle.

Now after a few more hours i saw an occasional connection to 2 of the torrents where they would upload a small amount of data (10-100mb) at terribly low speed and then disconnect.

I'm quite open to that torrents are "living" and dependant on the demand and such. But when the torrents down download when they come from RSS and repeatedly show completely different ammounts of demand as soon as they are added from another computer I'm more convinced that there is a problem with the machine in question.