jumperalex

that sounds like you are running out of memory / storage space. Are you sure you are not pointing any parts of the docker at either a very small drive. image, or in memory /tmp folder?

Absolutely, you're spot on regarding diminishing returns. That's why in my script I'm checking for the "Thriftiest" value, which is the lowest md_sync_window that returns at least 95% of maximum tested speed. (yes, I know that's an arbitrary threshold, but gotta draw the line somewhere, right?) From the same test run that produced those charts, here's what my script reported: The Fastest Sync Speed tested was md_sync_window=3392 at 131.6 MB/s Tunable (md_num_stripes): 6784 Tunable (md_sync_window): 3392 Tunable (md_sync_thresh): 3391 Tunable (nr_requests): 8 This will consume 547 MB with md_num_stripes=6784, 2x md_sync_window. This is 157MB more than your current utilization of 390MB. NOTE: Adding additional drives will increase memory consumption. The Thriftiest Sync Speed tested was md_sync_window=832 at 126.2 MB/s Tunable (md_num_stripes): 1664 Tunable (md_sync_window): 832 Tunable (md_sync_thresh): 831 Tunable (nr_requests): 8 This will consume 134 MB with md_num_stripes=1664, 2x md_sync_window. The "Thriftiest" value (832) was significantly lower than the value you chose (1920), and saves a ton of memory. It might be that 95% is too low of a threshold for the Thriftiest value. The value you chose is 99.6% of the maximum speed observed. Or maybe I need to change my algorithm to report the leading edge of the peak, instead of the absolute peak. I could look for the lowest value that gives 99%+ of peak observed speed, which would have returned 1408, or 99.5% which would give 1856. I still like to test for and report absolute maximums, but your absolutely right about using a lot of memory for very little gain. -Paul yup, I'm out of the loop 95%, 99.6%, 98% ... I guess the questing is what IS the real impact of all that memory usage? Because if it doesn't really matter, 99% seems good. If it does, then 95% seems like the place to draw the line. Either way, awesome work.

Its been a long time since I dove into this topic so I might be missing the obvious. Looking at that chart I have to ask; Are we looking at diminishing returns here? I'm wondering if memory usage and/or operational reads during the parity check are being impacted negatively from using higher values than needed? The curve seems to level out around 1920. From the variance in data I wonder if a practical value that would be 1920 where it appears you will get the same performance for the lowest value.

As someone who just did that ... hmmmm... is there a chance you didn't stop all torrents before you shut down the old docker? I can't be sure that is your problem but I have found sessions of most things don't like it if you don't close things out properly. In this case stop the torrents, then shut down the container, then copy session data, start the container, and start the torrents. Sort of how yuo have to stop the Plex server before you go copying the Library or it won't work; or used to not work at least. Frankly I wish we had a more graceful shut down of the container because without stopping the torrents your tracker will not be notified of the stoppage and will register that you are seeding the same file twice until it ages out of their system. In a typical application shutdown like utorrent on windows at least exiting the application also first generates a torrent stop being sent to the tracker. We can't exit the application in the docker and docker shutdown just seems to kill it. Next thing I know my tracker is blocking me for too many seeds until they time out But that is a tracker issue and not related to your problem exactly.

Success on all counts. When I figure out how to successfully reduce the autowatch interval (as opposed to the schedule interval in the rc) I'll post back. Thanks so much. Enjoy your movie!!!

OK very weird. This rss feed has always worked as entered. I played around and removed the bookmark portion and it loaded, but of course with a butt load of torrents that I don't care about. I put back the bookmark bit and it failed again. Of note is that right now I have no torrents to download because there is nothing new so my bookmarks list is empty. Next I manually added a bookmark at the tracker site and BAM ruTorrent saved the feed and shows only that single bookmark as expected. Soooo like I've said a few times now, this is my problem to deal with now not yours, but I'm adding this for any others that might have a similar problem. In fact it is known: https://github.com/Novik/ruTorrent/issues/1068 it is also in theory fixed, but I wonder if a regression was introduced

You rock man. I was gonna suggest that last bit about the commented line too hahaha So ... another rss feed loads fine. So many it is just the first tracker rejecting for some reason despite it loading in my browser and working on the old rutorrent ... coincidence I guess. but it is my problem to solve now, not yours. Thanks so much!!!

But but but ... it really is lovely. Does what I need and plays well with my trackers. Neither Transmission nor Deluge have I ever been able to get setup right. Maybe your permission change will help [shrug], but to be clear you're telling me you were able to click on the feed icon, enter in a feed url in the form of https://revolutiontt.me/rss.php?feed=dl&bookmarks=on&passkey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx and it worked? Because I get exactly Error loading feed. (https://revolutiontt.me/rss.php?feed=dl&bookmarks=on&passkey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) re: your image ... uggg ... I don't have even an idea where to start with my config that might make me so special. maybe I'll try another completely pristine docker, no session shenanigans, and see what happens

uggg while waiting I tried adding an rss feed and it will not load. "Error loading RSS feed" it is a feed I've used before and the url loads in my browser just fine. First google link is: http://forums.rutorrent.org/index.php?topic=65.0 if that helps Another similar issue http://forums.rutorrent.org/index.php?PHPSESSID=462ee4f8afb81093d2c735f62a52fe61&topic=288.msg1729#msg1729

oooooohhhhhhh of course. Thank you!

take the tilde "~" out and it's watched schedule = watch_directory_1,5,5,"load.start=/downloads/watched/*.torrent" I suppose I understand the tilde, but why "watched"? I specifically created a folder called watch. that said, removed the ~ but left it at "watch" and HOT DAMN it worked. [sigh] ... now I need to get it to remove the torrent file, but that is my problem to deal with Have you made the permission change? Should I kill and download the docker image / container? The autowatch tools are indeed easier to deal with from the GUI of course

I'm down with fixing the easy stuff first Also kinda makes the whole docker useless without it I await patiently. As always, thanks. And because I want to learn, at any time feel free to tell me to do more research with a bit of a hint where to start. Pieces are falling into place with this most recent comment, the php stuff, and my now trolling through your docker git

So I tried to manually add the torrent in question and this popped in the error log 2016/08/07 12:56:50 [crit] 235#0: *1 open() "/var/lib/nginx/tmp/client_body/0000000001" failed (13: Permission denied), client: 10.0.0.6, server: _, request: "POST /php/addtorrent.php?torrents_start_stopped=1& HTTP/1.1", host: "10.0.0.4:8081", referrer: "http://10.0.0.4:8081/" 2016/08/07 12:57:10 [crit] 235#0: *55 open() "/var/lib/nginx/tmp/client_body/0000000002" failed (13: Permission denied), client: 10.0.0.6, server: _, request: "POST /php/addtorrent.php?torrents_start_stopped=1& HTTP/1.1", host: "10.0.0.4:8081", referrer: "http://10.0.0.4:8081/" I've always been able to manually add torrents, so um ... now what? What other log should I send?

Ok so if I understand you, and please bare with me, php.ini is in "/etc/php7/" and right now is set to register_argc_argv = Off So as for you asking me to confirm that register_argc_argv = On enables autotools, all I can say is that is what I'm seeing on the intertubes but I can't confirm. Is there a comment I can execute to make the change on my system to test? I'm also seeing some notes that this fails using unix sockets. I assume that is as opposed to the option to use an scgi port? I'm getting some of this also from here http://forums.rutorrent.org/index.php?topic=57.0 Mind you I've also tried setting a watch folder in rtorrent.rc and that isn't working either. when trying one or the other I've made sure to disable one as well so they don't compete; then restart the docker. no luck with either and I don't care which I get working. my rtorrent.rc config line is schedule = watch_directory_1,5,5,"load.start=~/downloads/watch/*.torrent"

Quick question because I don't know how to check it myself, can you please confirm that within the docker container this is the correct path to PHP /usr/bin/php7 I ask because autotool for autowatch is not working and what I'm reading says the first thing to check is the path to php in the config.php file. The above is what I found. EDIT: also can you confirm, or not, if sorry if that is opaque, I'm trying to track down the issue with autowatch. that is another one of the "things to check" from here http://forums.rutorrent.org/index.php?PHPSESSID=557b64757da258035d65eb80f2a4ad26&topic=645.msg4895#msg4895

So two things: 1) now that I've updated, sure enough making changes to things like my connection port in the webgui do not stick on docker restart. So behaving as described 2) I copied over my entire session folder from my old appdata structure into the new appdate structure and all of my old torrents came over, connected to my private tracker, and started seeding as hoped for. So nuking the docker and appdata from orbit is not as much of a complete startover as I had worried. Thanks guys!!!

I have another candidate for FC: docker webui port mapping conflicts. Maybe I'm obtuse, stupid, or both but I just spent forever tracking down why my bridged containers that I just regenerated (due to linuxserver.io container reworks) would not start. Turns out, it was because they were defaulting to ports 80 or 8080 which are already owned. Sure you say, any experienced docker user should know that is something you need to change, BUT ... guess where that is mentioned BOLDLY in the docker config page? No where that I could find Sure you say, but unRaid's help dialogue says the following BUT ...you know what it doesn't say, it doesn't say that the docker will not even open or that you need to specifically ensure there are no conflicts. It says you CAN change the mapping, it doesn't say you MUST change the mapping. Sure you say, but the docker logs will tell you BUT ... that is the docker log, not the system log. The only way to get to the docker log via the GUI is to generate a diagnostics log which contains the docker log and then read it. Sure you can drop to the command line but really, is that the correct solution? So, I humbly suggest that FC checks for port mapping conflicts. I mean yes I think Limetech needs to do a better job of making all this very clear right in the UI, maybe even doing their own checking when the container is created and pop-up an error. If not that, then they need to do a better job of communicating the error in the logs somewhere to make it easier for the user to identify the failure issue. Like, maybe provide webgui access to the docker log. BUT I also know that the first thing I did was fire up FC to see if it would help me find the problem. It has become my go to maintenance and troubleshooter and I think this is a feature that can save people a lot of headache if they aren't paying attention to this "common problem" when installing a new / refreshed docker ;-) Thank you for your consideration

Just add an extra path in the docker webui on Unraid. Edit the container config and do it there. unfortunately even when i do add the path when trying to edit autotools to use this folder its stuck in the download folder? any changes made in the webui are not permanent and only apply to that session, ie until the docker is restarted. this is a limitation of the apps themselves https://github.com/Novik/ruTorrent/wiki#some-non-obvious-points any permanent changes need to be made to the rtorrrent.rc file /config/rtorrent/rtorrent.rc Weird because my changes three main settings i can think of seem to stick. I restarted my docker about an hour again and these settings were retained: feed interval watch folder unpack Or are those ruTorrent config settings and not rTorrent??

It should be easy to map the plex library on the array but transcoding to cache.

Yeah honestly at the least what is needed is a way to retain the users and their client certificated between updates. Needing to regenerate and reissue all user certificates, to all clients can be a real limitation for some people. Fortunately not me really since I have on user and two devices. But if I had a lot more I would certainly have to consider skipping some update points just to lighten the maintenance load and that isn't the best solution for security

gotcha on the rollout strategy thanks. Crash and burn ... uggg. At least for openVPN I only had a single certificate and two clients to reissue. I'm sure for more prolific users that would be a real PITA. I'll have to be strategic reseeding because doing them all will be serious hassle Well thanks for all the work though, it is appreciated.

I don't ruTorrent listed in OP and the page https://hub.docker.com/r/linuxserver/rutorrent/ seems like it isn't using the new image. Is support being dropped?

only if you limit its resources. my plex docker can do two BD rip to ROKU transcodes at the same time. See sig for specs.

any chance you recent;y changed your container mapping from a user share to a disk share? That will break things and require you to recreate the container. Your appdata will be safe though. I had to do that exact same thing.

Yeah not sure what is going on. My container's config is set to: /config /mnt/cache/appdata/plexmediaserver and then inside plex's webgui is set to: Transcoder temporary directory /config/transcode I just transcoded to my phone and watched at the segments populated my transcode folder. Soooo that is how it works for me. Full disclosure I am using neeto's docker but once you have set the /config folder for the container, Plex should respect a transcode folder designated inside of it.