td00

Got it! Thanks!

Hey All - I've got this up and running for a while now - great image thanks. Just a question though, it it possible to have a wild card URL entry? Kind of like the way google does with *.google.com? My current setup just has this: URL=topleveldomain.com SUBDOMAINS=portainer,sonarr,radarr But when I click to view the cert in the browser it seems that it sets portainer.topleveldomain.com as the URL and the rest in the SAN where they should be. Was just looking to see if possible to clean up. Currently, my topleveldomain doesn't point to anything if that makes a difference?

Thanks @Cat_Seeder I suppose this is my only option going forward. The only other problem is that PHP56 is located on the AUR.

Hey @binhex, Would it be possible for you to modify the image to include both PHP 7 and PHP56? The errors I'm getting with autodl might have to do with using PHP7 (which I know is probably preinstalled with the Arch image you're using) instead of PHP56. If you include it I might be able to go into the console and switch the versions to see if that corrects the issue.

Hey @binhex So I reached out to the autodl-irssi guys with the error. They said that it had to do with the version of PHP the image was using (currently your image is using 7.4.1 see here: https://imgur.com/TwKNPuP). They were saying that there have been reports of many issues with that version of PHP and that autodl-irssi recommends version 5 of PHP to run autodl-irssi successfully. I actually tried to downgrade your image with zero success lol (I guess that's the whole point of an image ) and I figure that the only reason the latest image is using newest version of PHP is probably the base image of arch you use to create the image. Anyway, I don't know/think you have any solutions to this (I suppose it doesn't make sense to recompile the whole thing for a PHP version) but just thought you should know in case there was anything you could do.

Howdy @binhex With your latest image I'm getting a bunch of these errors - looks like something to do with the different torrent trackers? Each error is the same but lists different trackers: 2020-02-06 19:41:48,202 DEBG 'rutorrent-script' stderr output: 2020/02/06 19:41:48 [error] 10556#10556: *1 FastCGI sent in stderr: "PHP message: PHP Notice: Trying to access array offset on value of type bool in /usr/share/webapps/rutorrent/plugins/autodl-irssi/getConf.php on line 54PHP message: PHP Notice: Trying to access array offset on value of type bool in /usr/share/webapps/rutorrent/plugins/autodl-irssi/getConf.php on line 61" while reading response header from upstream, client: 192.168.1.100, server: localhost, request: "GET /plugins/autodl-irssi/getfile.php?file=BrokenStones.tracker&_=1581018106166 HTTP/1.1", upstream: "fastcgi://127.0.0.1:7777", host: "192.168.1.118:9080", referrer: "http://192.168.1.118:9080/" This one happens to list "BrokenStones" which I don't use but still. Seems to go through each one that's built into autodl and then not start. Any ideas?

OK here's a weird one I just started getting: 2020-01-31 14:42:40,668 DEBG 'rutorrent-script' stderr output: 2020/01/31 14:42:40 [error] 871#871: *2926 FastCGI sent in stderr: "PHP message: PHP Notice: Trying to access array offset on value of type bool in /usr/share/webapps/rutorrent/plugins/autodl-irssi/getConf.php on line 54PHP message: PHP Notice: Trying to access array offset on value of type bool in /usr/share/webapps/rutorrent/plugins/autodl-irssi/getConf.php on line 61" while reading response header from upstream, client: 192.168.1.135, server: localhost, request: "GET /plugins/autodl-irssi/getlines.php?cid=34220718&_=1580499725887 HTTP/1.1", upstream: "fastcgi://127.0.0.1:7777", host: "192.168.1.118:9080", referrer: "http://192.168.1.118:9080/" Everything will be working fine, then after about an hour rutorrent will run into connection errors. Refresh the page and its unable to connect. Go into the logs and get this message over and over and over again. A restart of the rtorrent container brings it back until this happens again after about the same time. Any ideas?

Another update, one day passed since I rebooted to get everything working again and when I logged in... same issue. *Edit - Sept/30th/2019* OK so this is happening now every few hours.

Hey binhex, Ok, it's been a few days and unfortunately I've been away for a few days so I cannot tell you exactly what day it might have happened - but it did happen again ( Tracker: [Failed binding local connection end] error) and I've captured the logs starting from the day after the previous log post here: https://paste.ee/p/hpBU4 Here's hoping you can see what's up in these logs... keep up the great work and let me know if you need anything else from me.

Hey binhex, Ok I followed the directions and have my supervisord.log file for your review here: https://paste.ee/p/hegZp The only issue is that in following those directions, I had to restart the container in order to turn on the DEBUG mode per your request. Normally not a big deal however, restarting the container always fixes the Tracker: [Failed binding local connection end] error so I'm afraid you're most likely going to see a normal looking supervisord.log file. This seems to happen sporadically (usually after several hours of being up but typically within the 24-48hr range) where I'll check the web ui and notice all my torrents in red with this message for each of them. It isn't until I restart the container that it comes back working perfectly fine.

Hey binhex, One more question. It appears that your image comes coupled with rtcontrol which is great. I'm trying to run the following, rtcontrol is_complete=yes is_open=yes seedtime=+3d and it should return like 2000 results but I instead get: INFO Dumped 0 out of 2001 torrents. INFO Total time: 0.073 seconds. Just wondering if you're using some special version or something or if I'm getting this code wrong?

Hey binhex, So everything is running now but it seems now I'm getting Tracker: [Failed binding local connection end] on all my torrents after it refreshes the connection to VPN? I've pasted the log file here at the time it reconnected: https://paste.ee/p/yB9Yr I was searching around Google to see if I could figure it out myself but to no avail lol. The only thing I found that came close had to do with Transmission and how it used (or didn't use) IPv6 bindings in its curl scripts. Doubt it will help but just in case: https://github.com/transmission/transmission/issues/88

Hey binhex, OK I've pulled down your latest. However, this second tip here I went and looked in and found that the settings in my *.ovpn file seem to be indicating that it is in fact connecting with port 1198/udp: https://imgur.com/ge8Edhv I will keep an eye on it though and report back if I find anything. Thanks again for all the help!

Thanks binhex! Glad to know its not me Keep up the great work!

Yes sir it's right here: https://paste.ee/p/URgBB Thanks much for the help!

Hi BinHex, Loving your docker container! I keep running into an issue with it though that I hope you or the community might be able to help me with. I get it running with no issues and it downloads and seeds with no problems. However, I notice while letting it run and do it's thing that after a (long) while it goes down and fails to restart. I have posted the log here: https://paste.ee/p/ADI4A My assumption is that the VPN times out due to inactivity (in my case PIA) and the the container then fires a script to try and reconnect again but can't due to this error: "rtorrent: Error in option file: ~/.rtorrent.rc:134: Could not prepare socket for listening: Address already in use" Restarting the container corrects this by the way until of course it happens again. I am hoping you might be able to help me finally correct this so I can set it and forget it