deusxanime

I've noticed over the past week or so that some of my stuff has loaded into rTorrent, but was not starting or doing anything. I finally figured out that sometimes, upon loading, the Priority is being automatically set to "Don't Download" and/or the Channel is set to "up256" (which also has 0 set for download, thus stalled). Is there anything that has changed that might cause this? Not sure if those settings come from rTorrent or ruTorrent. I don't remember setting those in my rtorrent.rc file ever (and not even sure you can if they are part of ruTorrent), and even so I haven't edited my .rc file in months but this has suddenly started happening only recently. Going into settings in ruTorrent, my channels I think are still default and the "Default Channel" option is set to "Don't Set" so it shouldn't be automatically selecting any channel, much less up256.

Welcome to unRAID! It is a great system, sorry that your first experience as you are setting up is running into this year+ old bug that feels like it should have been resolved by now (considering Samsung is probably one of the most popular, if not the most popular, consumer SSD brand). Unfortunately it seems like some things get ignored/slip through the cracks, but for the most part it is really awesome. Kind of reminds me of Plex in that regard...

It would be nice to have this fixed. I bought two 1TB Samsung 850 EVOs a couple years ago when I switched to unRAID specifically to use as my cache drive in RAID1. Cost over $300 each and I've never been able to run them as a mirror properly in that time. Had to split them due to this issue and use one as my cache/appdata with XFS filesystem and just use the other as an unassigned drive with my VMs on it. Pretty big waste of space and money sadly.

Of course I was out of town when I found out it wasn't working, so just getting back to it now. I used to test it after every update, but I guess I got complacent and forgot to do that for a while now, so who knows how long it wasn't working. Now I'm back home and probably won't need it for a little while again, so I might wait until after this weekend or longer and see if an update fixes it eventually. It has been so long I have no idea how to set up from scratch anymore! I'll have to rewatch the SpaceInvaderOne video again to relearn how... Or maybe it's time to investigate alternatives like ZeroTier etc.

Did you ever figure this out or just have to delete your config folder and start over? Started getting the same things in my log and nothing working for me either now.

Something removed in the latest update/past week? After updating the container today, I'm having trouble installing some helper programs I use. I manually install mkvtoolnix (well with a script, but I have to start it manually) into the container after each update because I have some post-processing scripts that use mkvpropedit, among other things. I've been doing this for a couple years without issue, but today after updating now it can no longer install mkvtoolnix. Here's the script I use to install after updating the container: root@9833fbd4c5f7:/# cat /config/install_apk.sh #!/bin/bash -x set -x # sleep 15 /sbin/apk add mkvtoolnix --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted # for rename cmd etc /sbin/apk add util-linux --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted # for fixing accent chars need full sed (not busybox) /sbin/apk add sed --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted # added to container 3/20/18, shouldn't need to install manually anymore # /sbin/apk add nodejs --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted echo "ran on `date`" >> /config/Logs/install_helper_apps.log which mkvpropedit which rename which sed ls -l /bin/sed # which node # tail -f /dev/null set +x root@9833fbd4c5f7:/# Here's what I get for output now. Notice the "unsatisfiable constraints" error that comes up now: root@9833fbd4c5f7:/# /config/install_apk.sh + set -x + /sbin/apk add mkvtoolnix --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted ERROR: unsatisfiable constraints: so:libboost_filesystem.so.1.71.0 (missing): required by: mkvtoolnix-37.0.0-r2[so:libboost_filesystem.so.1.71.0] so:libboost_regex.so.1.71.0 (missing): required by: mkvtoolnix-37.0.0-r2[so:libboost_regex.so.1.71.0] + /sbin/apk add util-linux --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted OK: 94 MiB in 52 packages + /sbin/apk add sed --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ --allow-untrusted OK: 94 MiB in 52 packages ++ date + echo 'ran on Tue Oct 1 10:58:28 CDT 2019' + which mkvpropedit + which rename /usr/bin/rename + which sed /bin/sed + ls -l /bin/sed -rwxr-xr-x 1 root root 149616 May 3 15:44 /bin/sed + set +x root@9833fbd4c5f7:/# Not expecting you to alter the container for me, but if I know what I need to reinstall to get these working I can add it to my script at least and have it install that before mkvtoolnix installation kicks off. Edit: Doing some more digging, looks like maybe mkvtoolnix now requires the new boost 1.72.0 whereas the container is running 1.69.0. So I might have to find an older version of mkvtoolnix to run and/or wait to see if boost gets updated in the container (or figure out if I can upgrade boost myself). Edit2: Looks like I can force it to install an older version of mkvtoolnix (v34.0.0-r0 I believe is what this installs) that doesn't have that boost 1.72.x dependency by using this: /sbin/apk add mkvtoolnix --update-cache --repository http://dl-cdn.alpinelinux.org/alpine/v3.10/community/ --allow-untrusted This I think will work for now, though won't be sure until it downloads something and see if it does what it is supposed to do with mkvpropedit. Are there plans though to upgrade the Alpine to a version that uses new boost 1.72.x so that I won't need to fiddle with this in the future?

Do you have a link to the hotfix info? Have had issues with 4K playback on my Samsung TV and wonder if they are finally getting around to fixing it. Edit: Nevermind, I think I've found it. Looks to be a recent issue that cropped up in past few days in a server update. My issue is much older and this doesn't seem like it addresses it. Edit2: Btw, it looks like the fix for the issue @showstopper is talking about has been pushed to Plex Pass users, so restart the container and it should pick it up - v1.16.5.1554-1e5ff713d.

It was a bit of a journey getting to unRAID, but don't plan on leaving anytime soon now! Been loving it the past few years. Here's to many more!

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.