Squid

Gah! I checked there however I was looking for a CA icon under Settings and not an entire section. Thanks! That would be because of what CHBMB calls bloat. [emoji2] Sent from my LG-D852 using Tapatalk

Go to the settings tab. The settings button taking you to the apps tab is an oversight of mine in the .plg file Sent from my LG-D852 using Tapatalk

Just ignore it. I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results. I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed. Another example, with a little more detail: No problem on Aug 11, claims clock off by 5 hours 8 minutes (so not a timezone issue) on Aug 12. Noticed this message about 9:30am, did a plugin check at 9:47am just to put a timestamp into log, and it was perfect. No apparent clock corrections, just a check against the wrong time (under some condition, randomly generated?). (still on 6.1.9) It's never going to be a time zone issue as I'm comparing Unix epoch times. But rather its an issue on the time server's end. I'll look around for another server that suits my needs or modify the code to issue it as an other warning or something. Sent from my LG-D852 using Tapatalk

It still was there (at least in RC2 for experimental hardlink support on user shares), but that's about the only reference I can find for it anywhere on the forum with 6.2

You should be able to parse /var/local/emhttp/disks.ini In the [parity2] section it has an IDX label (which on my system spec in sig) comes up with 29

No. You would have to manually copy it back to the appdata folder. Doing what you suggest would delete everything else in the appdata folder. If you're running 6.2RC3+, then its easy as you can just copy / paste the folder (as 6.2 support symlinks through user shares) On 6.1, I would do it through something like Dolphin or Krusader docker apps and copy directly from the disk share

Unless you're one of the users that had the parity check slowdowns on the SAS2LP's. Then nr_requests has a significant effect. Yes, that's why I said to always set it to 8, it benefits SAS2LP users (also a little SASLP users) and doesn't make any difference for LSI and other controllers, all my servers are set to 8, most don't have SAS2LP. Had to reread the nr_requests thread. I thought that since unRaid has a default now of 128 that was the fix. But looks like 8 was the fix. 128 is probably just for safety sake.

If you're on 6.1.x you have to hit advanced, then force updates. Due to changes @ docker Hub, the update checks do not work on 6.1 anymore

Unless you're one of the users that had the parity check slowdowns on the SAS2LP's. Then nr_requests has a significant effect.

It only takes time. And if you come up with the best combination, then I'm sure nobody will mind.

Just ignore it. I have to check the time against an internet server that reports the unix epoch time and if something happens on it then the error also results. I just re-ran the tests and everything is ok, so whatever issues that server was having is now fixed.

The thing about nr_requests is that it is per drive, and different drives (and what controllers they are attached to) respond differently to it (as I understand it - could be completely off base here) EG: I have the SAS2LP. For the longest time, I never believed anyone when they stated that it was returning slow parity checks, as I never experienced the issue. As it turned out, by a fluke, the drives that I had that were affected (IIRC using ATA-8 for the interface version) were not attached to the controller, so I never noticed the problem. Had they been attached to the controller, then I would have. As it stands, the nr_requests fix didn't have any affect on my system because I had never been affected by the problem in the first place due to how potentially affected drives were connected. By extension of this, there are still reports of certain Samsung drives when involved in an array causing slow parity checks, but when doing normal reads/writes run full speed. I guess that the problem with nr_requests now is that if you can get better results by individually setting the value per drive, then unRaid is going to clobber those set values on a reboot as it only offers a global setting to apply to all drives. You could probably get around this by having a secondary script to set individual nr_requests when the array starts however. Probably would be wise to PM eschultz on nr_requests, since he figured that one out in the first place.

The extra parameters section isn't available in the GUI, and as a noob I didn't know how to edit the template xml file, but after a bit of research I found that I could edit it in windows via the flash share. Anyway thanks for the pointer, I just deleted the <ExtraParams> inner text and the docker now installs and runs, I haven't got the HDhomerun working but I suspect that is a Tvheadend configuration setting. KaySeeOne What version of unraid? I checked on both my 6.1.9 and 6.2rc4 and its there under both basic and advanced view You might want to check for plugin updates also Sent from my LG-D852 using Tapatalk

It looks obvious that I need to set the --device path, but how? One other thing I do not have a physical TV adapter installed in the unRAID server but I was planning to use a network HDhomerun tuner. Thanks in advance for any help with this. KaySee You edit that in the extra parameters section. No idea about what to do with a network tuner. But I guess you could just delete the line and see what happens

That helps catch me up, thanks! I was going to ask about it, and nr_requests. I've got some ideas for preliminary testing of md_sync_thresh, so I'll add that into the mix and see how it goes. I was also going to ask if Tom had ever revealed how md_num_stripes vs md_sync_window works now that md_write_limit is gone. The script I'm currently testing I never released to the public, and it has Write testing. I had found that md_write_limit had a large impact on write speeds, and now that it is gone, I don't know what to think. I think I had a pretty solid understanding of md_num_stripes in 5.0, but now I'm lost. Any rules of thumb for setting num_stripes vs. sync_window? I also see a new tunable named md_write_method, with selectable values of read/modify/write, or reconstruct write. What in the world is that? -Paul Memory wise it's not a big deal anymore even worrying about the extra that un throttled takes over best bang. Although I had found in my 6.0 days that on one of my old servers unthrottled really brought to the forefront if you had cabling wasn't up to snuff while the slower best bang didn't. Sent from my SM-T560NU using Tapatalk

Nr_request was what solved the aoc-sas2lp problem. That was because certain hard drives running a certain version of ata interface firmware would slow down parity checks. Start here http://lime-technology.com/forum/index.php?topic=42629.msg417261.msg#417261 and http://lime-technology.com/forum/index.php?topic=42629.msg417447.msg#417447 md_write_method isn't really a tunable but rather a setting. What it does if it's set to reconstruct mode (on tapatalk so not sure what the actual setting is) then all drives get spun up to do a write and then instead of the having to read the parity disk to see what the existing parity value is calculate what the new parity value would be and then write it, all the disks (except for the one being written to and parity) are read concurrently and parity and data disk are written to simultaneously. Much faster writes depending upon the width of the array and the number of disks currently spinning. Side note you would think that setting it to auto turns it off and on depending upon if all the drives are spinning or not, but auto means the same as disabled Sent from my LG-D852 using Tapatalk

Nope more or less a flat line. Script actually seemed to return lower values than what a actual parity check would do at the start of it, but I didn't really take the time to ensure the server was set up for an optimal parity check time (didn't stop any thing else running on the server at the time of my quick test). My secondary server however had a flat line running 5.x / 6.x probably due to the Br10i controller, and its results under my hack pretty much match exactly my parity check rate. (and it is nothing but a NAS) I believe it is less of an issue than what it was (that and combined with the fact that the script didn't work without modification of the paths under 6.1 and wouldn't work at all under 6.2 without removing two lines), but the tunables are still in the OS, and many people out here simply want the best possible performance out of their hardware possible. I do still see intermittently some users (johnny.black?) posting to users to adjust their tunables, but those suggestions have always seemed to me to be off-the-cuff based upon his own experiences, and may not be suitable to all user's hardware. My own system when on 6.0 showed a definite bell curve with this script and higher values helped to a point and after the peak was reached, the rates dropped precipitously. Only time will tell if there is still a need for adjusting tunables if people (hopefully) begin posting their results again.

It just popped into my head while I was at work and spent an entire 2 minutes determining which lines wouldn't let it run under 6.2, commenting them out (my local copies I had long ago made the change in the directory for the move in mdcmd) The underlying algorithms you are the best expert on that with regards to the script, and with my changes I make no guarantees at all that anything even works. All I know is that if I happen to set the md_sync value to an obscene number (so low as to guarantee that I'm going to get a low rate), the script does indeed work. Beyond that, under 6.2 I've had zero problems and am really happy with the rates that the default values return (and the script basically returns a flat curve for the different test points), and my 6.1.9 server has always returned a basically flat curve. I basically did this to help out Frank1940 in another thread as it couldn't hurt to modify the script for 6.2 functionality (and as I already stated I was bored at work) Should you decide in the future to reconfigure the script from being interactive to instead taking command line switches for everything, then I can help you out with a plugin front end for it.

Since I always found this script to be of immense use, here is the modified script that will work under 6.2 and under 6.1.9. Only difference for 6.2 compatibility is that md_write_limit has been removed from 6.2, so the adjustments that the script makes as it runs have been removed. (Note that it will still display the md_write_limit values in the summary) (it was setting the md_write_limit that would crash the script on 6.2 even with changing the location of mdcmd within the original script) And you should really read Pauven's comments a couple posts up (http://lime-technology.com/forum/index.php?topic=29009.msg424206#msg424206) This script is not the end-all-be-all, but can help. It did for me back in the day, but now my system works fast enough using LT's default values) unraid-tunables-tester.zip

Akin to how the name is (headless), there is zero need to ever hit the webUI on this container. (and the webUI doesn't even work properly since this is basically a hack of Kodi designed specifically just to update the library) Rough directions on how to set up You need to have an already working kodi so that you can do the initial scan and then copy over the sources.xml (may also require passwords.xml ->can't remember) And you then point your download clients to point to this app to automatically update the library instead of pointing it at a HTPC.

plugin: checking unRAIDServer.plg

If you have both SNAP and UD installed they may interfere with each other. SNAP should no longer be installed Sent from my LG-D852 using Tapatalk

You can't do the latter unless you use Unassigned Devices to mount that windows share Ok thanks, I try to search for a little more detail on how to configure this docker with not much success is there another rout to set it up such as create a folder on the unraid? Thanks again Lou Never installed it at all so can't really help you there. All I could do was point out that if you wanted it to use your library on your windows box you would have to use unassigned devices to mount the share.

You can't do the latter unless you use Unassigned Devices to mount that windows share

Glad that the problem is solved, but didn't CA show you under every icon that docker was not enabled? (Plugins would still be installable via CA) Trying to see if I have a bug here or not.