deusxanime

FYI for anyone that uses this with TorGuard - they just released a new certificate (ca.crt) and so you need to update that file (should be in your "openvpn" folder of your appdata directory for this container) in your config otherwise it won't connect anymore. I lost track of the actual error from the container log since I restarted it, but it was similar to what they show on TorGuard's website - "TLS_ERROR: BIO read tls_read_plaintext error". If you see that or something similar, it is probably the issue with their new cert needing to be loaded.

I thought for this docker container you had to use the rtorrent.rc because anything you configure in the GUI/ruTorrent is not persistent between restarts? Or do some of the settings you configure in the GUI actually get written back to the .rc file? I have always just used the .rc file since before this I was running rTorrent on a headless system anyway.

You might want to review all your settings if you are still using those old parameters. They were depreciated for quite a long time actually and finally had support completely removed for them months back. I had the same problem with some other settings as well (must have used an old guide to set it up originally so I was using many of the older deprecated parameters) and went back through and realized I had to redo quite a bunch of them to get things working properly again. Don't remember what version that happened in, but it just kind of stopped working all at once because of that.

Well I'm just subscribed to a bunch of threads and saw the discussion. Wasn't looking for any specific support myself.

Ah I realized what it was... I use binhex's rtorrent-vpn container, which uses tmux instead. Didn't realize I was in lsio's thread! Whoops.

Is that right? Swear the couple times I've done it in the past it was tmux. Or did it get changed at some point?

Interesting, didn't know there was such a thing! I'll give it a try. Thanks!

I mostly use this with Mega, which it is awesome with, but I've been running into other sites (RapidGator, UploadGIG, etc.) that requires a browser to do the captchas and since it is running in a container of course this doesn't work. I don't think there is a way to get the link to open elsewhere/outside the container either, and that probably wouldn't work anyway since it would see it coming from a different location I imagine. Is there anyway to put in a simple/basic install of Chrome or Firefox maybe into the container to allow those to open up and be done?

I'm on multiple private trackers and have been able to seed with no problem and keep my ratio quite good.

I feel like this is a myth that gets touted around a lot. I use TorGuardVPN with this thread's namesake container and there is no port forwarding going on, yet I can get multiple Mb going in both directions without a problem. So I don't think port forwarding/direct connection is as important as it seems.

I don't have quite as many people as @IamSpartacus, usually a few at a time is my max, but haven't had any major issues with RAM transcoding (I have /transcode in the docker mapped to /tmp and set in Plex server settings). It might matter how much actual memory you have in your system. Of course that is only going to work if you have enough to spare. I have 64 GB in my server. What I have noticed that started over the past few weeks is I get tons of "buffering" messages coming from Tautilli, but nobody remote is really complaining to be about any problems so I have mostly been ignoring them for now.

Thanks, I was able to change things around using that URL to the web console. Took a bit to figure out where to change it, but after some digging I found the setting.

Do I lose device, backups, progress, etc? Or will that all get sorted out and restored when I bring it back online?

I don't see anything useful, but just in case here you go. The container had been sitting and running and 19:51 is when I logged in. It comes up with that "warn" as soon as logging in, so not related to this issue. I go to change the setting from 15 minutes to something else, and as soon as I hit the dropdown, the GUI crashes (or at least goes all blank other than the top menu). No messages shows up in the ui.log though until I force exit (File > Exit) and then you see the sending exit message. Both ui_error.log and ui_output.log are blank and stay that way. 2018-10-23T19:51:02.153Z - info Screens.Login: Login request was successful 2018-10-23T19:51:02.154Z - info AppInit: Set application state to be logged in 2018-10-23T19:51:02.154Z - info Screens.Login: Requesting application startup data 2018-10-23T19:51:02.167Z - info AppInit: Register authenticated event handlers 2018-10-23T19:51:02.167Z - info AppInit: Requesting all application initialization data 2018-10-23T19:51:02.240Z - info Screens.Login: Finished requesting application startup data 2018-10-23T19:51:02.641Z - warn RestAdapter: Error making service request to https://127.0.0.1:4244/v1/Setting/org-securityTools-enable : Not Found 2018-10-23T19:51:48.136Z - info: Sending exiting message to service 2018-10-23T19:51:48.177Z - info: Sent exiting message to service. Quitting 2018-10-23T19:51:48.911Z - info: ************************************************************ 2018-10-23T19:51:48.913Z - info: Name: CrashPlan 2018-10-23T19:51:48.913Z - info: Version: 6.8.3 2018-10-23T19:51:48.913Z - info: Options: _=[], showMenubar=false, showDesktop=true, isDevEnv=false, isTestEnv=false 2018-10-23T19:51:48.913Z - info: Platform: linux (x64) 2018-10-23T19:51:48.913Z - info: Service Info: /var/lib/crashplan/.ui_info 2018-10-23T19:51:48.913Z - info: Log File: /config/.code42/log/ui.log 2018-10-23T19:51:48.913Z - info: ************************************************************ 2018-10-23T19:51:49.114Z - info: Setting locale after receiving loginSetup to AUTOMATIC_LOCALE 2018-10-23T19:51:49.116Z - info: Connected to service, show main window 2018-10-23T19:51:49.605Z - info: Updating system locale to en_US 2018-10-23T19:51:50.281Z - info: Closing splash screen 2018-10-23T19:51:50.236Z - info JS Console: Init browser console logging 2018-10-23T19:51:50.238Z - info main: Starting application initialization 2018-10-23T19:51:50.244Z - info ServiceInterface: init() with https://127.0.0.1:4244 2018-10-23T19:51:50.283Z - info: Showing main window 2018-10-23T19:51:50.242Z - info main: Initialized ipc listeners to main process 2018-10-23T19:51:50.244Z - info main: Initialized push event interface to service 2018-10-23T19:51:50.245Z - info main: Initialized https interface to service 2018-10-23T19:51:50.265Z - info main: Performed localization loading, attempting to connect to the service 2018-10-23T19:51:50.288Z - info main: Connected to the service 2018-10-23T19:51:50.288Z - info main: Attempting to fetch customizations for un-authenticated state 2018-10-23T19:51:50.290Z - info main: System locale en_US did not match the locale returned from the service AUTOMATIC_LOCALE, requesting the correct locale 2018-10-23T19:51:50.306Z - info main: Attempting to auto-login 2018-10-23T19:51:50.308Z - info main: A token is available, test if the token is valid 2018-10-23T19:51:50.311Z - info main: Current token is not valid, initialize routing to login 2018-10-23T19:51:50.326Z - warn JS Console: Attempting to access localized key before initialization. 2018-10-23T19:51:50.320Z - info main: Starting main routing 2018-10-23T19:51:50.326Z - warn JS Console: Attempting to access localized key before initialization. 2018-10-23T19:51:50.326Z - warn JS Console: Attempting to access localized key before initialization. 2018-10-23T19:51:56.669Z - info Screens.Login: Login request was successful 2018-10-23T19:51:56.670Z - info AppInit: Set application state to be logged in 2018-10-23T19:51:56.669Z - info Screens.Login: Requesting application startup data 2018-10-23T19:51:56.685Z - info AppInit: Register authenticated event handlers 2018-10-23T19:51:56.685Z - info AppInit: Requesting all application initialization data 2018-10-23T19:51:56.777Z - info Screens.Login: Finished requesting application startup data 2018-10-23T19:51:57.072Z - warn RestAdapter: Error making service request to https://127.0.0.1:4244/v1/Setting/org-securityTools-enable : Not Found Don't feel bad, I keep doing that too! The scroll bar is pretty slim and unobtrusive, so I miss that the list is scrollable and think something is missing, only to realize that I just need to scroll down...

I was previously using your CrashPlan for Home container, so I followed the procedure in the OP to migrate over (copied the appdata from "CrashPlan" to "CrashPlanPRO" directory, then started up the Pro container).

Just switched over from regular CP to CPP/SB. Trying to resetup my backup and change a couple settings and the GUI keep crashing when trying to change the scan frequency. Go to Settings (gear icon) > Backup Sets > "Frequency and Versions" Change... button > "Backup changes every" dropdown As soon as I hit that dropdown to change to something else besides 15 minutes, the GUI crashes. The only thing left up is the top menu bar. From there I can do File > Exit and it will restart the GUI and ask me to login, but as soon as I go back in and try to change that setting it crashes the GUI again.

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.

In your custom cron entry, you have a "*" character in the first slot which makes it so it is set to try to run at every minute during the 3:00 AM hour. * * * * * * | | | | | | | | | | | +-- Year (range: 1900-3000) | | | | +---- Day of the Week (range: 1-7, 1 standing for Monday) | | | +------ Month of the Year (range: 1-12) | | +-------- Day of the Month (range: 1-31) | +---------- Hour (range: 0-23) +------------ Minute (range: 0-59) So it kicks off at 3:00 AM and runs and then if it completes before 4:00 AM (so any 3:XX time) it tries to run again. If you want it to only run at 3:00 AM you need this for your custom cron entry: 0 3 */3 * *

Thanks, I'm going to give that a try to start with. I'll have to resolve to do more backups of my containers and VMs, but otherwise hopefully the performance improvement will be worth it.

So, I'm at a point where I can make some changes to my server drive layout and trying to decide what the best move forward plan is for now. I currently still have 2x Samsung 850 EVO 1TB drives in BTRFS RAID1 for my cache pool. Pretty much the worst case scenario it seems after reading back through this thread again. (And let me tell you that my ~$600 investment is really chapping my hide that unRAID people seems to not care about these issues at all, rendering it crippled.) Should I just split up the pool and reformat one of the drives in XFS to use as my new cache drive/pool, and then I can just do whatever with the other in Unassigned Devices? If I do that, what is the issue with alignment on Samsung SSDs and will that still cause problems? Or is that only an issue with BTRFS and not a problem with XFS? In which case the only solution to get the max performance out of them would be to use a tool to fix the alignment, rendering them both only usable in UD since unRAID won't work with them that way? Or should I just say screw it and buy a new SSD to use as cache to avoid the above issues? Thought I still can't use BTRFS RAID1 since that is not a manufacturer specific issue right? Ugh, where is the "just works" I wanted when moving to (and paying for) this product...

There's been a few releases since the last post, but I don't think anything has been fixed yet correct? Any idea if/when that will happen? Debating whether to keep chugging away with my BTRFS RAID1 cache pool or just split it and format as XFS.

Looks like they released a new v3.9.0 the past week and you need to update a few parameters to get it working with the new version when you upgrade, if you were previously running this container. Likely you had a mapping from [container]/root/.shoko/ to [host]/mnt/user/appdata/shokoserver/. The [container] path needs to be changed now to /home/shoko/.shoko/. Also you need to find your unRAID host's /mnt/user/appdata/shokoserver/Shoko.CLI/settings.json file and update any references in there that still point to /root/.shoko/ and change them to /home/shoko/.shoko/ as well. I had 6 different places I had to update that in my settings.json file, not sure if that would be the same for everyone but be aware there are multiple. FYI, for anyone else that might be using Shoko Server container on their unRAID.

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

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?

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?