jumperalex

Fixed it for me too. Anyone know the issue and if it is something for linuxserver to fix or further upstream?

sadly no. I really haven't thought about this issue since DarkHorse's post.

haha fair play. I've never had any other "worse" problems. But yeah now I know. I wonder if that might be something worth adding as a caution actually in the docker overview box? "Note: This Docker image is more dependent on an up-to-date image than you might be used to. Any application problems may be solved by a docker update" or something like that ... Just saying. And saying Thank You!

I update every month on schedule. Forcing a docker update now ... yup, there are updates ... done ... and there I can now see it grabbing the new plexpass version in the log using the same url that I said I found on plex.tv myself. That is rather annoying 😛 But now I know. Thanks.

Resurrecting this a bit ... so based on what you said I do indeed see that version 1.15.0.659 is available as a plexpass verison for me. But my log says it still isn't available. Atempting to upgrade to: 1.15.0.659-xxx https://downloads.plex.tv/plex-media-server/1.15.0.659-xxx/plexmediaserver_1.15.0.659-xxx_amd64.deb: 2019-02-16 10:09:37 ERROR 404: Not Found. ######################################################## # Upgrade attempt failed, this could be because either # # plex update site is down, local network issues, or # # you were trying to get a version that simply doesn't # # exist, check over the VERSION variable thoroughly & # # correct it or try again later. # ######################################################## I've been running for quite some time and updates have occurred in the past. I'm on 1.14.1.5488 right now. I recall a while back seeing an update issue but I ignored it at the time and it "went away" some time later when I next looked. I chalked it up to resolved connection issues, but now I'm thinking it "went away" because the plexpass version moved to stable and the download succeeded. I do see mention on the git readme about "IMPORTANT NOTE:- YOU CANNOT UPDATE TO A PLEXPASS ONLY (BETA) VERSION IF YOU ARE NOT LOGGED IN WITH A PLEXPASS ACCOUNT" which makes me ask, logged in where? inside my plex docker instance? yup, done that. In a parameter of the docker set-up? I don't see where to do that. On my desktop I can download the 1.15 verison, and did as a test. But the link for THAT is "https://downloads.plex.tv/plex-media-server-new/1.15.0.659-xxx/debian/plexmediaserver_1.15.0.659-xxx_amd64.deb which is different than where the dockers seems to be attempting to pull from. While logged into the plex.tv website the docker link doesn't work from my browser either. But maybe the deb version is what I should be testing against? Any help is appreciated and by all means tell me what other info I might need to provide.

Is anyone having any luck getting the preview function to work? I mean when I click PREVIEW it opens a window that shows me an image that represents what will be encoded size / aspect wise but I don't see an option to get an actual 10sec playable click like discussed here: https://handbrake.fr/docs/en/1.1.0/workflow/preview-settings.html

Like it so far. You know its weird I hate light themes on phones and do everything I can to make it as dark as possible. And I run a dark theme on Reddit (technically a dark grey and maybe that's the difference) but for just about every other forum i prefer a light theme. I don't know what it is about the dark theme for unraid I don't like, but I just don't. If I can put my finger on it and it's not just a weirdness of me I'll post it here fwiw.

I didn't want to get greedy ... you rock, Thanks Squid!!!

Love this! Is it possible to increase the size of the editing window? Wider and taller. Feels like I'm looking through a periscope for some larger file (like rtorrent.rc)

Just wanna say, I finally got around to shifting my BD drive from my desktop to my server to try this out and WOOT!!! Worked like a charm!!! Now I can buy a smaller desktop case and makes my workflow muuuuuch shorter and smoother. THANK YOU!!!

Thank you for this. I brain locked on where to find as.conf LSIO, it might be worth updating the github instructions to add the "appdata/" bit

I seem to have the same issue. Did you erase the appdata openvpn folder and start over fresh? I have all my devices setup and would hate to have to recreate it all. Thanks Yes that is what I had to do. I only have one user and two devices so I wasn't too concerned about retaining settings. You might get away with just moving the bin folder out of there and see if it recreates correctly. Or go the other way and start with a fresh appdata folder and then can you import your device connection settings?

hmmm I just tonight told it to update from the Docker tab. I take I just need to delete the whole thing? So I removed the container and the image. Repulled from CA and I'm still looking at 2.1.2 Would it be because I reused my appdata folder without emptying it? EDIT: [sigh] yup that was it. cleared out appdata. I'm sure somewhere in this thread it is mentioned.

sooo openvpn-as is now up to version 2.4 but I only seem to grab 2.1.2 .... am i missing something?

I don't see why that matters though. Of course different algorithms produce different hashes. But the user doesn't have to change algorithms when they change hardware. They can, but they don't gave to. It won't be the fastest choice from that point on, but right now it isn't the fastest choice either. So I see that as a wash with the benefit of having the fastest choice on first use and the option to start over if it is important enough on new hardware.

meh, I think if different machines produced different results we'd have heard about it by now. Blake and Blake2 are hardly untested. https://tools.ietf.org/html/rfc7693 You might as well judge SHA harshly because SHA-256 makes different hashes than SHA-512. I admit it would have been nicer if single vs parallel made the same hash but from what I've read of the technical articles, it is a different way of constructing the hash and a different result is impossible to avoid or it wouldn't be as much of a speedup. Blake2s vs Blake2b not making the same has also makes sense since, well they aren't even the same length. So, I'm not sure what would lead you to make the leap from different algorithms creating different hashes to the same algorithm creating different hashes on different machines? Still, I don't see portability as a concern. The user can choose which Blake2 algorithm to use just like they choose to use Blake2 over SHA or MD5. It is no more or less portable than any of the other hash functions that produce different hashes. Also, should a verification check generate a metric sh!t ton of failures, that might indicate the wrong algorithm is being used so maybe double check against the other options. It should be fairly obvious and just needs to be an user option when verifying. If nothing else the hash check code can cut the options in half just by looking at the length of the hash, b is longer than s. So really what should probably happen is one algorithm has to be chosen on install (and that might be overly restrictive), by the user, and then a warning issued if the user changes it. Practically speaking that is only going to happen for anyone moving from something without AVX to something with it. After that they'd literally have no reason to change ever again until another faster better algorithm is created. Just like when everyone moved from MD5 to SHA-256 to SHA-512. And they don't even HAVE to change (ie start over) because all that will happen is they will not be running the fastest most secure hash for their system. A fact already true right now. As for saturating the system, I sure hope the OS is smart enough to load balance, but even if it isn't, that it why you run it at night when nothing else is going on. Other than the implied ask of you doing more work I don't see the problem with offering user choice.

Some quick testing on my windows machine (because I am lazy) showed the following timed results for a 1.32GB file on an SSD with an AMD PhenomII X4-975 -h blake2b: 4.39s (I can't tell what this is optimized for other than 64-bit) -h blake2s: 6.79s (optimized for 8- to 32-bit) -h blake2bp: 2.04s (optimized for 4-way parallel) -h blake2sp: 2.83s (optimized for 8-way parallel) I don't know which parameter is being used by this plugin but clearly even on a "modern" CPU it can make a large difference. If I had to guess, my 8-core unRaid cpu probably would do better on the 8-way optimized and would probably get even more benefit from the fact that it implements a more modern instruction set to include AVX, FMA4, and XOP which my desktop does not. Makes me wonder if your C2750, being an 8-core will benefit from using the either the blake2bp or even blake2sp hash function?

Right from the webpage https://blake2.net/ There is also this document https://131002.net/data/papers/NA12a.pdf which describes the benefits of the AVX2 instructions which ATOMS don't appear to have So it might be worth it to test the others versions and use the fastest ... maybe dynamically at install

yeah you might have other issue i guess. Best i can say is a clean slate start as a test. keep your old session and appdata, but first eliminate any question that there is something bad left over from your old install. I do know though that rtorrent still might benefit from some work on a graceful shut down given how my trackers claim I'm seeding from multiple locations if I don't stop all my torrents before a restart. I don't have that problem with my windows client when i shut it down because it isn't having its virtual plug pulled.

yup. of course the easier way if you already have to do something manual is to select all your torrent, click stop, wait, then kill the docker as usual [shrug]. That should have the same effect of notifying the tracker and ensuring your state is clean. but of course then you have to restart the torrents and that can be annoying if you have choosen not to seed everything you have. just a though for how little I know it is worth

permissions are all or nothing, all of your torrents would behave the same if that were the case. i suspect it's more to do with the nature of docker itself , stop / restart the container on some instances can be likened to basically pulling the plug on a running computer. Sparkly I can't tell, are you this dockers dev / maintaner? Was looking at wrong Git ... I see that you are sooooo Would it be possible to modify the shutdown command to include a stop of all torrents with a wait period? that would have two benefits 1) give rtorrent a chance to notify the trackers and 2) let rtorrent itself set the torrent's state correctly I don't think I'm telling you anything new but the start of my research leads me here: https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/ The next question of course is, what does rtorrent need for a graceful shutdown And sheesh I should just wait to write this stuff but I'm impatient and like to record what I learn in steps ... rtorrent wants to see a SIGINT sent. https://bbs.archlinux.org/viewtopic.php?id=118686 Here I go again ... thinking ... is this even controllable by the container? I feel like this might be more of an unRaid GUI issue for bonienl. He might need to make it possible for the docker author, or the user, to edit what is sent when we click the STOP option in the Docker UI. This guys docker https://github.com/kfei/docktorrent has a note

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.