[Support] binhex - rTorrentVPN


Recommended Posts

7 hours ago, binhex said:

 

 

why not get rutorrent to do the moving, it works seamlessly (as in rutorrent/settings/autotools), i have been using this for some time and havent had an issue with it either on the previous version of rtorrent or the current version.

 

note if you do enable it in the web ui ensure you disable it in the rtorrent.rc to prevent any potential conflict.

hi

   m8

 

thanks  for  that  I  done  that  and it looks like it  is  moving them  when  done  is  the a way to delete the torrent file  when done

 

thanks

 

backupking

Link to comment

Updated rTorrent+VPN just now (not sure when the update came out, but only got a chance to do the update today) and now it won't start. Was running fine before. I see this in the log just repeating over and over now:

 

2018-06-12 21:04:06,902 DEBG 'rtorrent-script' stdout output:
[warn] Wait for rTorrent process to start aborted

2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output:
[info] rTorrent not running

2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output:
[info] rTorrent not running

2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2018-06-12 21:04:37,032 DEBG 'rtorrent-script' stdout output:
[info] Attempting to start rTorrent...

2018-06-12 21:04:37,033 DEBG 'rtorrent-script' stdout output:
Script started, file is /home/nobody/typescript

2018-06-12 21:04:37,059 DEBG 'rtorrent-script' stdout output:
Script done, file is /home/nobody/typescript

2018-06-12 21:04:37,060 DEBG 'rtorrent-script' stdout output:
[info] Autodl-irssi not enabled, skipping startup

 

Link to comment
14 hours ago, deusxanime said:

Updated rTorrent+VPN just now (not sure when the update came out, but only got a chance to do the update today) and now it won't start. Was running fine before. I see this in the log just repeating over and over now:

 


2018-06-12 21:04:06,902 DEBG 'rtorrent-script' stdout output:
[warn] Wait for rTorrent process to start aborted

2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output:
[info] rTorrent not running

2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2018-06-12 21:04:37,030 DEBG 'rtorrent-script' stdout output:
[info] rTorrent not running

2018-06-12 21:04:37,031 DEBG 'rtorrent-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2018-06-12 21:04:37,032 DEBG 'rtorrent-script' stdout output:
[info] Attempting to start rTorrent...

2018-06-12 21:04:37,033 DEBG 'rtorrent-script' stdout output:
Script started, file is /home/nobody/typescript

2018-06-12 21:04:37,059 DEBG 'rtorrent-script' stdout output:
Script done, file is /home/nobody/typescript

2018-06-12 21:04:37,060 DEBG 'rtorrent-script' stdout output:
[info] Autodl-irssi not enabled, skipping startup

 

 

can you post the file /config/rtorrent/config/rtorrent.rc here its probably an entry in that thats no longer compatible with the newer rtorrent 0.9.7

Link to comment
3 hours ago, Ryonez said:

Has something happened in the last update?

All of the torrents trackers are no longer responding. Tried switching the vpn to a different endpoint, put no dice. 

 

not that would cause this. no, the only thing it might be related to is a bump up to rtorrent 0.9.7, maybe the tracker doesnt allow this version yet and thus its blacklisted/not allowed.

Link to comment
5 minutes ago, binhex said:

 

not that would cause this. no, the only thing it might be related to is a bump up to rtorrent 0.9.7, maybe the tracker doesnt allow this version yet and thus its blacklisted/not allowed.


I've got this happening on all of my torrents, it's not just one tracker affected.
This could be a problem...

 

Link to comment
3 minutes ago, binhex said:

 

and the trackers are all private trackers?

 
No. Though it seems some are responding now.

They were working before I restarted the docker hours ago, I'll see if restarting it again drops them off again.

Link to comment
4 hours ago, binhex said:

 

can you post the file /config/rtorrent/config/rtorrent.rc here its probably an entry in that thats no longer compatible with the newer rtorrent 0.9.7

 

Here's my rc file. Hopefully it's something simple like that.

 

 

Edited by deusxanime
removed rc file since we got it fixed
Link to comment
1 hour ago, deusxanime said:

 

Here's my rc file. Hopefully it's something simple like that.

rtorrent.rc

 

ive found at least one issue with your rtorrent.rc file:-

rtorrent: Error in option file: ~/.rtorrent.rc:62: Command "system.method.insert" does not exist.

 

so that command no longer exists in rtorrent 0.9.7, or has been changed so you will need to google and find out what the newer style command is. now there could be more, this was just the first one i found, if after removing the above command rtorrent still doesnt start then you will need to keep plugging away removing commands one at a time, you can do this using the following procedure:-

 

open unraid web ui/docker/left click container and select console, copy and paste the following:-

 

/usr/bin/rtorrent

keep running this and modfying the rtorrent.rc file until you receive no errors, once its running then close the console window and restart the container.

Link to comment
28 minutes ago, binhex said:

 

ive found at least one issue with your rtorrent.rc file:-


rtorrent: Error in option file: ~/.rtorrent.rc:62: Command "system.method.insert" does not exist.

 

so that command no longer exists in rtorrent 0.9.7, or has been changed so you will need to google and find out what the newer style command is. now there could be more, this was just the first one i found, if after removing the above command rtorrent still doesnt start then you will need to keep plugging away removing commands one at a time, you can do this using the following procedure:-

 

open unraid web ui/docker/left click container and select console, copy and paste the following:-

 


/usr/bin/rtorrent

keep running this and modfying the rtorrent.rc file until you receive no errors, once its running then close the console window and restart the container.

 

Thanks for the info. It appears that system.method.* was deprecated and I should now just be using method.* for those parameters. Had a few in there that I changed and got it to start up. They must have fully removed them now in this release. Found the info here for anyone wondering (under the Method section).

 

Also, I tried what you said and clicked the container and opened the console (when it still wasn't working), but when I put in and try to run "/usr/bin/rtorrent" I get a "no such file or directory" error. Was able to get it working luckily without needing that, but for future reference something that I might have done wrong?

 

edit: Must have been some weird character coming over from copy-pasting from webpage, because if I type the "/usr/bin/rtorrent" in manually it works just as you said (and tab-completes yay!). Thanks again!

 

 

Edited by deusxanime
see above
  • Like 1
Link to comment
2 hours ago, karateo said:

i am using the non-vpn docker and I asked there for auto-unpack plugin but didn't get any response.

 

Is anybody using it successfully?

If yes, can I use this docker without using VPN?

 

the 'unpack' plugin is included yes, i dont personally use it so i cant comment on how well it works, and yes you can use this container without the vpn part by setting env var key VPN_ENABLED to 'no'.

  • Like 1
Link to comment

I noticed that my watch/import directories weren't working, even after I got rtorrent going again from my previous startup issues. Upon investigation, it seems that there are tons of updated commands and parameters (see the page I linked above) and I ended up having to basically rewrite/recreate my rc file from scratch!

 

FYI in case anyone else is seeing things not working as expected since the latest update, you may have outdated parameters that don't work or aren't recognized correctly anymore.

 

Here's the new "base" rc file example from github if you need to start from scratch like I did.

 

Edited by deusxanime
Link to comment
I noticed that my watch/import directories weren't working, even after I got rtorrent going again from my previous startup issues. Upon investigation, it seems that there are tons of updated commands and parameters (see the page I linked above) and I ended up having to basically rewrite/recreate my rc file from scratch!

 

FYI in case anyone else is seeing things not working as expected since the latest update, you may have outdated parameters that don't work or aren't recognized correctly anymore.

 

Here's the new "base" rc file example from github if you need to start from scratch like I did.

 

I've actually included the new style base rtorrent.rc file so all new users will now be using the newer commands, but obviously there is going to be quite a few support requests for existing users for some time, I might need to create a FAQ for this.

 

Sent from my SM-G935F using Tapatalk

 

 

 

Link to comment
30 minutes ago, binhex said:

I've actually included the new style base rtorrent.rc file so all new users will now be using the newer commands, but obviously there is going to be quite a few support requests for existing users for some time, I might need to create a FAQ for this.

 

Yeah I couldn't believe it even started for me as it was. I pretty much had to fix and/or redo every line of my file. 

Link to comment

Anyone else using SickRage to send to this rTorrent container? Mine was working ok previously (occasional failures to send, but would work the next time, or would add in stopped state), but since the last update things are failing to send over completely now. SR tries to send magnet links via scgi to rTorrent and I just get this error every time now it tries to send over:

2018-06-15 09:03:07 SEARCHQUEUE-DAILY-SEARCH :: Error while sending torrent:
2018-06-15 09:03:07 SEARCHQUEUE-DAILY-SEARCH :: rTorrent: Unable to send Torrent

I double-checked my rTorrent connection settings in SickRage and everything is still the same as before (basically just put in the scgi address and leave other stuff blank/default) and pushing the Test button gives me a Success message saying it is working. But everything SR tries to send over just fails now with above error message.

 

Not sure if something has changed in the way rTorrent handles/accepts magnet links or what, or yet another parameter change that needs to be updated from the old version, but it has been a couple days trying to figure it out and no luck. I tried switching to Black Hole method in SR instead, but it is horrible at grabbing actual torrent files to send to a watch directory, so that doesn't work either.

 

edit: Is there a way to use XML/RPC method with rTorrent in this docker, rather than direct scgi? Wonder if that would work better?

 

Edited by deusxanime
Link to comment

So I figured out the URL for direct XMLRPC is http://<server_IP>:9080/RPC2 and you use Digest authentication with your username and password. Using that in SickRage I was able to get it to give me the "Success: Connected and Authenticated" when pushing the Test Connection button in settings. But I still end up with the same errors when it tries to send the magnet link over to rTorrent.

 

Just wondering if anyone else is seeing that with the new version of this container or what others are using as their settings in SickRage (or SickBeard or Medusa I think are the same) to get stuff over to rTorrent?

Link to comment
So I figured out the URL for direct XMLRPC is http://:9080/RPC2 and you use Digest authentication with your username and password. Using that in SickRage I was able to get it to give me the "Success: Connected and Authenticated" when pushing the Test Connection button in settings. But I still end up with the same errors when it tries to send the magnet link over to rTorrent.
 
Just wondering if anyone else is seeing that with the new version of this container or what others are using as their settings in SickRage (or SickBeard or Medusa I think are the same) to get stuff over to rTorrent?
For what it's worth I'm using medusa with latest tTorrent with no obvious issues, I see torrents added to rtorrent queue from medusa

Sent from my SM-G935F using Tapatalk

Link to comment

Hello,

 

I am having a lot of issues with the latest version (or the latest versions, haven't updated in a few weeks until today)

Seems to be issues with reporting the correct IP?

 

Getting "Tracker: [Failure reason \"Invalid IP detected\"]" from a few trackers,   and from old torrents that I have been seeding a while:  "Tracker: [Failure reason \"401: You cannot download or seed the same torrents from more than 3 locations\"]"

Link to comment
On 5/7/2018 at 1:55 PM, dprus said:

I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider.

 

The script that detects my public IP fails about 90% of the time because ... 


# from /root/getvpnextip.sh
$(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')

returns a IPv6 address rather than IPv4 as expected by the script.

 

Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from 


curl ipinfo.io/ip

by exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.

 

Were you ever able to solve this issue? I'm also using Mullvad and I'm having the exact same issue...

 

No.. BinHex never issued a fix.  I'm sure I could edit the script, but I would much rather have it a "supported" solution.

 

Sorry for the delayed response, I guess I am not getting email notifications.

Edited by c0nfuzed
correction.
Link to comment
On 6/16/2018 at 6:08 AM, binhex said:

For what it's worth I'm using medusa with latest tTorrent with no obvious issues, I see torrents added to rtorrent queue from medusa

Sent from my SM-G935F using Tapatalk
 

 

Yeah I've been meaning to switch over to Medusa or Sonarr eventually. This might be the final nail in the coffin for SickRage.

Link to comment
20 minutes ago, deusxanime said:

 

Yeah I've been meaning to switch over to Medusa or Sonarr eventually. This might be the final nail in the coffin for SickRage.

 

medusa also has working jackett support which is awesome, i believe its still broken in sickrage, once you get jackett working correctly it really is very nice.

Link to comment
Quote
  On 3/6/2018 at 10:20 PM, c0nfuzed said:

I just found a bug, it only appears to have started recently so I suspect something changed at my VPN provider.

 

The script that detects my public IP fails about 90% of the time because ... 


# from /root/getvpnextip.sh
$(dig -b ${vpn_ip} TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')

returns a IPv6 address rather than IPv4 as expected by the script.

 

Additionally, and I'm not sure why, but when it does return an IPV4 address it is always different than what I get from 


curl ipinfo.io/ip

by exactly 1... so if google's dns is reporting my IP is 1.1.1.1 then ipinfo.io/ip is reporting that it's 1.1.1.2... I don't fully understand why they would be different, but I fear that googles dns is wrong... might explain why I am not seeding as well as I would like.

 

So after a bit of screwing around, I fixed my issue by creating a replacement getvpenextip.sh and mounting it into the container as follows.  This new file uses the old DNS lookup method first, but if that fails it falls back to using curl to get the ip from http://checkip.amazonaws.com followed by http://whatismyip.akamai.com (both stable web presences).

 

To test this:

 

1. create a file called getvpenextip.sh on the host OS containing:

#!/bin/bash

# define name servers to connect to in order to get external ip address
pri_ns="ns1.google.com"
sec_ns="resolver1.opendns.com"
pri_url="http://checkip.amazonaws.com"
sec_url="http://whatismyip.akamai.com"
retry_count=30

# remove previous run output file
rm -f /home/nobody/vpn_external_ip.txt

# wait for vpn tunnel to come up before proceeding
source /home/nobody/getvpnip.sh

# function to check ip address is in correct format
check_valid_ip() {

        check_ip="$1"

        # check if the format looks right
        echo "${check_ip}" | egrep -qE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' || return 1

        # check that each octect is less than or equal to 255
        echo "${check_ip}" | awk -F'.' '$1 <=255 && $2 <= 255 && $3 <=255 && $4 <= 255 {print "Y" } ' | grep -q Y || return 1

        return 0
}

while true; do

        if [[ "${DEBUG}" == "true" ]]; then
                echo "[debug] Attempting to get external IP using Name Server '${pri_ns}'..."
        fi

        external_ip="$(dig -b ${vpn_ip} -4 TXT +short o-o.myaddr.l.google.com @${pri_ns} 2> /dev/null | tr -d '"')"
        check_valid_ip "${external_ip}"
        return_code="$?"

        # if empty value returned, or ip not in correct format then try secondary ns
        if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then

                if [[ "${DEBUG}" == "true" ]]; then
                        echo "[debug] Failed to get external IP using Name Server '${pri_ns}', trying '${sec_ns}'..."
                fi

                external_ip="$(dig -b ${vpn_ip} -4 +short myip.opendns.com @${sec_ns} 2> /dev/null)"
                check_valid_ip "${external_ip}"
                return_code="$?"

        fi

        # if empty value returned, or ip not in correct format then try first URL
        if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then

                if [[ "${DEBUG}" == "true" ]]; then
                        echo "[debug] Failed to get external IP using Name Servers, trying '${pri_url}'..."
                fi

                external_ip="$(curl --interface ${vpn_ip} ${pri_url} 2> /dev/null)"
                check_valid_ip "${external_ip}"
                return_code="$?"

        fi

        # if empty value returned, or ip not in correct format then try secondary URL
        if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then

                if [[ "${DEBUG}" == "true" ]]; then
                        echo "[debug] Failed to get external IP using Name Servers and primary URL, trying '${sec_url}'..."
                fi

                external_ip="$(curl --interface ${vpn_ip} ${sec_url} 2> /dev/null)"
                check_valid_ip "${external_ip}"
                return_code="$?"

        fi

        # if empty value returned, or ip not in correct format then retry
        if [[ -z "${external_ip}" || "${return_code}" != 0 ]]; then

                if [ "${retry_count}" -eq "0" ]; then

                        external_ip="${vpn_ip}"

                        echo "[warn] Cannot determine external IP address, exausted retries setting to tunnel IP ${external_ip}"
                        break

                else

                        retry_count=$((retry_count-1))

                        if [[ "${DEBUG}" == "true" ]]; then
                                echo "[debug] Cannot determine external IP address, retrying..."
                        fi

                        sleep 1s
                        continue

                fi

        fi

        echo "[info] Successfully retrieved external IP address ${external_ip}"
        break


done

# write external ip address to text file, this is then read by the downloader script
echo "${external_ip}" > /home/nobody/vpn_external_ip.txt

# chmod file to prevent restrictive umask causing read issues for user nobody (owner is user root)
chmod +r /home/nobody/vpn_external_ip.txt

2. mount it over the container's version using the mount option: 

-v <host path>/getvpnextip.sh:/root/getvpnextip.sh:ro

 

Hopefully BinHex will see this and consider updating his script.  In the meantime this seems to be working for me.

 

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