[Support] binhex - rTorrentVPN


Recommended Posts

On 9/22/2018 at 5:43 AM, binhex said:

In that case you should simply download the newer ovpn config file that includes the new encryption type and replace the one in /config/openvpn/

Sent from my SM-G935F using Tapatalk
 

I edited the config file as follows and it works! Thanks.

cipher aes-128-gcm
auth sha256
ncp-disable

 

  • Like 1
Link to comment
On 9/24/2018 at 3:29 AM, binhex said:

Are you by any chance using mirrored cache drives. or have /config pointing at host path /mnt/user/....

Sent from my SM-G935F using Tapatalk

For me, yes. I just changed them. Lets see if theres a difference :) It's been like this since the beginning though!

 

 

*Edit* Nope, only took a few hours for rutorrent to start refusing my connections. I can confirm the torrents arent seeing as Ive had several or my torrents removed for being dead on a few sites.

 

Log just says 

2018-10-12 19:06:55,118 DEBG 'watchdog-script' stdout output:
[info] rTorrent running

Nothing else is happening

Edited by DazedAndConfused
Link to comment

I spent the last 6 hours searching the forum reading advice and testing things to try to solve the problem with some torrents not downloading because of port 6881 and the red ball at the bottom because of this port.  It's a super easy fix, but was not explained in any one place and I thought I might save someone else a ton of time in the future.  So here goes my quick tutorial.  

First, you need to open a port though your VPN (NOT YOUR ROUTER).  AirVPN which is well supported has a simple page to use, pick a number between 10000 and 50000 and use it for both the Port number and local port number.  This is a great first step, it will keep you from picking a port already in use.

Second, make sure the docker is stopped and open the rtorrent.rc file it should be located at appdata\binhex-rtorrentvpn\rtorrent\config. 

On each of the following lines you will need to delete the # at the beginning of the line

On line 77 change the range of network.port_range.set = make the starting and ending number your port number from the first step. 

On line 115 set dht.mode.set = on 

On line 119 dht.port.set = your port number

Save the file and start the docker.

I hope this helps someone in the future.

Edited by usabigguy
  • Like 2
Link to comment

Tried playing with the docker this weekend, looking to see if I could use it to replace my delugevpn docker (one thing deluge is missing that I'd like to see is information about what blocks/pieces are downloading and/or missing).

Ran into 2 major issues:

1) Ports being listed as not open. I figured out how to modify the rtorrent.rc file to set custom ports, but still didn't work. Admittedly, this could be an issue with my VPN provider, but haven't seen anything from deluge indicating that this is an issue.

2) And this is the bigger issue for me: I couldn't get magnet links to work. With Deluge, I just needed to copy the link, paste it as a URL, and the torrent kicks off without issue. Trying a similar process with rtorrent, it just hangs there with the torrent labelled as the magnet hash value. It wasn't until I did a full download of the torrent and importing of it that things would start to work.

 

The other thing that was getting at me was that my testing torrents were listed as having errors, but I couldn't find anything that would tell me what the actual errors were. The logs tab would only show me general data about the whole rtorrent environment, and nothing else I poked at seemed to show things.

Link to comment
21 hours ago, Caldorian said:

2) And this is the bigger issue for me: I couldn't get magnet links to work. With Deluge, I just needed to copy the link, paste it as a URL, and the torrent kicks off without issue. Trying a similar process with rtorrent, it just hangs there with the torrent labelled as the magnet hash value. It wasn't until I did a full download of the torrent and importing of it that things would start to work.

 

 

The other thing that was getting at me was that my testing torrents were listed as having errors, but I couldn't find anything that would tell me what the actual errors were. The logs tab would only show me general data about the whole rtorrent environment, and nothing else I poked at seemed to show things.

 

I can't say what causes that issue with magnet links but I get the same thing from time to time. When my Medusa container sends torrents to rTorrent they usually are magnets and so I see that hash value initially if I'm keeping an eye on it. They usually take a few minutes to resolve into actual torrent names, sometimes they take longer, and sometimes (rarely though) they never resolve and I have to force a new download. Not resolving ever though is not common and have only had to do that a few times. Try to just give them a while and see if the magnet hashes eventually resolve into torrents and start working.

 

As for the errors on torrents, I see that as well. I think it flags them as an "error" even if it something minor like one of the trackers is timing out. Try looking on the General tab, that is where I usually see that timeout message on them under "Tracker status". Just leave it and it should continue working just fine. It will continue using the ones it can and try to reconnect to the ones timing out. Also make sure you have DHT running so that it will connect to other clients even without good tracker connections.

 

Link to comment

I'm having an issue with the rTorrent container. I can't change the port from 6881-6999, and the DHT port from 6881.

 

Pretty much every private tracker and ISP on earth blocks port 6881 and other common torrenting ports.

 

How do I change this port? It's set to 8118 in the container settings but trying to change it from within the WebUI doesn't work. Changing it and stopping torrents does nothing. Sites still report it trying to use 6881. Changing it and restarting the container just sets it back to 6881-6999.

 

@binhex You should consider changing the default port to something else far more obscure. Most ISPs are okay with ports above 60000 and not many ISPs block those.

screenshot-192.168.1.50-2018.10.27-02-33-23.png

Link to comment
On 10/27/2018 at 12:35 AM, plantsandbinary said:

I'm having an issue with the rTorrent container. I can't change the port from 6881-6999, and the DHT port from 6881.

you need to change the incoming port and dht port in the rtorrent config file located in /config/rtorrent/config/rtorrent.rc see the comments in the file.

 

On 10/27/2018 at 12:35 AM, plantsandbinary said:

How do I change this port? It's set to 8118 in the container settings but trying to change it from within the WebUI doesn't work.

8118 is used for privoxy (you know that right?), changing it in the web ui should just work, can you expand on what you mean by "doesn't work"?

 

On 10/27/2018 at 12:35 AM, plantsandbinary said:

You should consider changing the default port to something else far more obscure. Most ISPs are okay with ports above 60000 and not many ISPs block those.

the default incoming port is not actually set to 6881, so not sure where you are seeing that, its actually set to 49160, not that it really matters as the vpn connection will dictate what port you use, you cant just set it to what you want.

Link to comment

Thanks for the reply. 6881-6999 is what it shows in the RuTorrent WebUI. It's also what is written by default inside the appdata rtorrent.rc file. I wasn't sure whether or not it mattered.

 

When checking stats from many of my trackers they report rTorrent using port 6881. Unless I edit the rtorrent.rc file and change the port to something else. So are you absolutely sure that it is running on 49160?

 

In my case my VPN sadly doesn't allow port forwarding so I don't have the option to open ports or use the ones they provide as they don't provide any. I'll change providers next year but for now this is what torrent sites report my port being listed as (6881).

Edited by plantsandbinary
Link to comment
20 minutes ago, plantsandbinary said:

my VPN sadly doesn't allow port forwarding so I don't have the option to open ports

Which means you can't use that VPN with trackers that require real seeding. Opening ports in your router is meaningless if you are tunneling through the VPN.

Link to comment
51 minutes ago, jonathanm said:

Which means you can't use that VPN with trackers that require real seeding. Opening ports in your router is meaningless if you are tunneling through the VPN.

Yes I know this, but regardless I'm still able to seed at line speed, trackers just don't see me as 'connectable' and nothing can be done about that.

Link to comment
1 hour ago, plantsandbinary said:

It's also what is written by default inside the appdata rtorrent.rc file

not sure why your rtorrent.rc file is defined as that but its not that in the default rtorrent.rc file included with the docker image, see link below:-

 

https://github.com/binhex/arch-rtorrentvpn/blob/master/config/nobody/rtorrent/config/rtorrent.rc

 

as you can see from the link above the port defined on line 77 (commented out due to code to auto set it for pia vpn provider) is 49160, in any case its a moot point as you have stated above you are with a vpn provider who doesnt provide port forwarding and thus it doesnt matter what its set to you will never have a incoming port.

 

1 hour ago, plantsandbinary said:

When checking stats from many of my trackers they report rTorrent using port 6881

if you dont have an incoming port (which you dont) then im not sure how any tracker can be detecting you on ANY port.

Link to comment

I'm not sure either. NordVPN is a bit confusing when it comes to torrenting. They have P2P optimised servers which I use, but they don't allow port forwarding.

 

At least before I changed any settings what-so-ever in the RuTorrent WebUI or in the rtorrent.rc file. The line was commented out in the .rc file, but I uncommented it out after some trackers complained that I was using port 6881 which is blacklisted on almost all trackers. RuTorrent WebGUI said it was using ports 6881-6999 and for DHT it was 6889 or something, I can't really remember. At least 6881 was the port trackers were reporting that I was using on the client info page on-site. For those sites I just used qBittorrent for the time being.

 

Anyway I uncommented out line 77 like I said and changed it to 49160-49160 (it still apparently has to be a sequence, because if I write just '49160' the container won't start). Now tracker sites are reporting that's the port I am indeed using. When I tried changing the WebUI's 6881-6999 setting before (whilst leaving line 77 commented in, in it's default state), it did nothing, and always changed back upon a restart of the container.

 

I don't know any more than that and I'm not accusing anyone of anything. rTorrent has always been a bit confusing for me haha. Either way sites aren't complaining now and I don't care if I am not connectable, sure it's a bummer but if it was so important I'd just disable the VPN because my ISP doesn't block any ports except TCP 25 and UDP 53 for security purposes only, literally every other port is free to use. Still I'd rather not have them see what I am downloading :) Maybe one day all these trackers will swap to HTTPS. Seeding now at a steady 19MB/s, so I'm not complaining.

 

Thanks for your work anyway. It's fantastic to have a container that I just can throw my .ovpn file in and it basically works without a hitch. Now I just need to wait until this subscription is over next year and I'll look for another VPN. Shame because I really, really like Nord.

Edited by plantsandbinary
Link to comment
12 hours ago, plantsandbinary said:

When I tried changing the WebUI's 6881-6999 setting before (whilst leaving line 77 commented in, in it's default state), it did nothing, and always changed back upon a restart of the container.

 

I don't know any more than that and I'm not accusing anyone of anything. rTorrent has always been a bit confusing for me haha.

yep this is completely normal, in short rutorrent (web interface to rtorrent) allows you to save settings ONLY for rutorrent, so saving settings for any rutorrent plugin will work, HOWEVER if you want to save any settings for rtorrent, such as incoming port, then the only want to do this (and make it save between restarts) is to define it in the rtorrent.rc file, rutorrent does NOT write out settings to the rtorrent config file (rtorrent.rc) and never will (according to the author) - see my FAQ for more details.

 

12 hours ago, plantsandbinary said:

Thanks for your work anyway. It's fantastic to have a container that I just can throw my .ovpn file in and it basically works without a hitch.

np :-).

Link to comment

Are there any good way to skip the usage of a download folder? 

I'm using the auto-tools plugin and have a directory listing as below, together with that I'm using the filters to place the torrent files in the specific Movie/Series folder that it should be located in when it's downloaded

Data
 - Movies
 - Series
    - Simpsons
    - Better call saul
 

So I'm placing the file in "Simpsons", it starts the downloads in  /Data/Incomplete/Series/Simpsons, I dont have the need to use a download folder, I would just want it to download directly into  /Data/Series/Simpsons. 
I tried removing the default download directory from rtorrent.rc, but then it placed the downloads in /usr/share/webapps/rutorrent/plugins/autotools/Movies"


 


 

Link to comment
3 hours ago, martikainen said:

Are there any good way to skip the usage of a download folder? 

I'm using the auto-tools plugin and have a directory listing as below, together with that I'm using the filters to place the torrent files in the specific Movie/Series folder that it should be located in when it's downloaded

Data
 - Movies
 - Series
    - Simpsons
    - Better call saul
 

So I'm placing the file in "Simpsons", it starts the downloads in  /Data/Incomplete/Series/Simpsons, I dont have the need to use a download folder, I would just want it to download directly into  /Data/Series/Simpsons. 
I tried removing the default download directory from rtorrent.rc, but then it placed the downloads in /usr/share/webapps/rutorrent/plugins/autotools/Movies"


 


 

do you want ALL downloads to go into the Simpsons folder?, if so then set the completed folder as /Data/Series/Simpsons. however i find this unlikely, in which case your best bet is to use an app to do this for you, such as sonarr, medusa or sickchill, any of these will automatically delete crud files, rename the folder and files to match the show and episode and then move the folder to the array for you, they can even trigger library updates for kodi, plex, emby etc, this is how nearly everybody else does it.

 

in short you have to have a completed folder somewhere to differentiate between a partially downloaded file and a completed download (a partially downloaded file will look exactly the same as a completed file (auto fill)).

Edited by binhex
Link to comment

Any way you could set

tty: true

to address the CPU usage bug in rtorrent with curl? The fix was applied in another rtorrent docker and seems to have fixed the 100% core usage from rtorrent.

Edit:
Switching to the advanced tab, and adding "-t" to the extra parameters addresses this issue as well. No longer is one core stuck at 100% usage.


Edit2:

I realize you are using TMUX to work around that issue; so the -t or tty: true quirk is unapplicable since tmux *should* appear as a TTY to rtorrent.


May I also suggest switching to a socket file instead of the ports based system? It seems more stable to me for Flood at least.

I've edited the /home/nobody/rtorrent.sh and /home/nobody/flood.sh to wait for the creation of the rpc.socket file like so:


        until [ -e /tmp/rpc.socket ]; do
                sleep 0.1
        done


And updated the config files as appropriate to use the rpc.socket instead of the network settings. Edited by Xaero
Link to comment
23 hours ago, binhex said:

do you want ALL downloads to go into the Simpsons folder?, if so then set the completed folder as /Data/Series/Simpsons. however i find this unlikely, in which case your best bet is to use an app to do this for you, such as sonarr, medusa or sickchill, any of these will automatically delete crud files, rename the folder and files to match the show and episode and then move the folder to the array for you, they can even trigger library updates for kodi, plex, emby etc, this is how nearly everybody else does it.

 

in short you have to have a completed folder somewhere to differentiate between a partially downloaded file and a completed download (a partially downloaded file will look exactly the same as a completed file (auto fill)).


Simpsons was just an example, each series is placed in their own folder. I have no interest in renaiming, unpacking or moving files. I'm running plex and rar2fs so it wouldnt be a problem downloading to a "completed folder". Thats why I was asking if it was possible to skip the usage of a temp folder for downloads. 


It's not a big problem to use a download folder, but i've noticed that sometimes rtorrent seem to fail with something while moving data from temp folder to completed downloads, the data is moved but rtorrent still thinks the data is in the temp folder, so i need to manually point rtorrent to the new location and do a "force recheck" before it will seed. 


But thanks for the quick answer Binhex! And thanks alot for this awesome container! 
If you accept suggestions, would it be possible to add mail notifications?  https://pmourlanne.wordpress.com/2013/04/27/rtorrent-receiving-an-email-when-a-download-is-complete/

Link to comment

The little CPU plugin in ruTorrent is showing really high CPU usage (80-100%) when I get to about 20MB/s but my connection can do a lot faster download than this. Any idea why this happens? My unraid control panel is showing my CPU usage at only about 10-15%. So it's not even close to 100% like ruTorrent UI is saying it is.

Edited by plantsandbinary
Link to comment
4 hours ago, plantsandbinary said:

The little CPU plugin in ruTorrent is showing really high CPU usage (80-100%) when I get to about 20MB/s but my connection can do a lot faster download than this. Any idea why this happens? My unraid control panel is showing my CPU usage at only about 10-15%. So it's not even close to 100% like ruTorrent UI is saying it is.

Try setting "-t" as an extra parameter in the advanced tab and seeing if you still see the abnormal CPU usage reporting.

Link to comment
On 11/1/2018 at 2:19 AM, Xaero said:

Any way you could set


tty: true

to address the CPU usage bug in rtorrent with curl? The fix was applied in another rtorrent docker and seems to have fixed the 100% core usage from rtorrent.

Edit:
Switching to the advanced tab, and adding "-t" to the extra parameters addresses this issue as well. No longer is one core stuck at 100% usage.


Edit2:

I realize you are using TMUX to work around that issue; so the -t or tty: true quirk is unapplicable since tmux *should* appear as a TTY to rtorrent.


May I also suggest switching to a socket file instead of the ports based system? It seems more stable to me for Flood at least.

I've edited the /home/nobody/rtorrent.sh and /home/nobody/flood.sh to wait for the creation of the rpc.socket file like so:
 


        until [ -e /tmp/rpc.socket ]; do
                sleep 0.1
        done

 


And updated the config files as appropriate to use the rpc.socket instead of the network settings.

thanks for this, although as you rightly say i am using tmux i too also see the 100% cpu usage shown in rutorrent bottom (no cores are showing 100% cpu however via top) bar so at least i got something to go at, i will give tty: true a go, if it solves the issue i will stick it in one of the startup scripts, its a little bit cryptic as to what the hell that really achieves, esp as i have term=xterm already set, but hey what do i know :-).

 

edit - bit more poking around, for me adding -t option to docker run doesnt fix the issue, not sure how to pass tty: true via web ui, it doesnt seem to take it, not sure if that is a docker compose option only, so for now i dont see a way around this other than simply ignoring it. i might try a later build of curl and see if this fixes it up.

Edited by binhex
Link to comment
On 11/2/2018 at 1:56 AM, Xaero said:

Try setting "-t" as an extra parameter in the advanced tab and seeing if you still see the abnormal CPU usage reporting.

Hi mate. Do you mean somewhere here?

 

screenshot-192.168.1.50-9443-2018.11.03-13-42-22.png

 

Or do you mean somewhere in the container settings?

 

Thanks for the reply btw!

 

EDIT: Okay Binhex said it might not do anything, I guess I could just disable the CPU plugin then if I wish or wait until something is done about it. Either way I only wanted to know if it's something to worry about. I thought maybe I needed to give the container more RAM or CPU or something, but I didn't think that was even possible as I thought Docker containers run straight through the main machine's resources rather than like a VM, taking a portion of system resources. Anyway if it's nothing to worry about, then I'll ignore it.

Edited by plantsandbinary
Link to comment
5 hours ago, plantsandbinary said:

Or do you mean somewhere in the container settings?

I meant in the docker settings

And yes, it's perfectly acceptable to just ignore the WebUI reporting 100% CPU usage as long as the Unraid WebUI is not ALSO reporting 100% cpu usage. I'm nitpicky though so I like everything to look perfect lol.

Link to comment

Yes it is cosmetic, my guess is that the cpusage plugin is not compatible with the latest kernel now included with unraid 6.6.3, I'm pretty sure this was working fine previously with unraid 6.5.x

And yeah adding a pseudo terminal does not fix it (-t flag)

Sent from my SM-G935F using Tapatalk

Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.