jumperalex

5.11.39 has been deemed stable according to this https://community.ui.com/releases/UniFi-Network-Controller-5-11-39/6ab8ef1a-376f-41e6-85b2-ceec098b8462 Sadly, as you're surely aware, they still haven't pushed to the repos. [sigh]

"posted" as in to the LIO servers or Ubiquiti's? They are already at Ubiquiti and I'm using latest.

soooo what needs to be done to get on the 5.11.39 version?

FWIW, I have a marvell controller (HighPoint Rocket 620 2-port) and upgrade went fine. IOMMU group 18: [1b4b:9120] 05:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9120 SATA 6Gb/s Controller (rev 12) [1b4b:91a4] 05:00.1 IDE interface: Marvell Technology Group Ltd. 88SE912x IDE Controller (rev 12)

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