Squid

Wattage doesn't matter. Amps per rail are what counts. The key with that power supply is that it has 2 12volt rails, each rated at 32A individually, or for a combined maximum of 56A) It doesn't look like Athena has a manual online, but you need to check out what 12v1 and 12v2 actually power. IF the hard drives are running off of the same rail as the CPUs (ie: both are on 12v1 and 12v2 is dedicated to the PCIe connectors (not an unusual situation), then you are really pushing the supply to the limit (and beyond) due to the spinup current required by the drives. Side note, PSU for server's running actual RAID systems can generally be rated lower than what is necessary for unRaid. This is because under a normal RAID system, the drives are running 24-7, and during boot up, you would generally enable the controller to spin the drives up individually rather than all at once (which happens say at the start of a parity check), to keep the current draw at a minimum

Oops... Yeah, I always forget that But, in the case of any user wishing to only be notified about certain plugins having an update and not others the procedure works (on 6.3+)

The notifications that you're seeing are from one of two places (or both) Dynamix telling you that there's an update available -> can be disabled completely under notifications settings FCP complaining that there's an update available -> you can ignore this warning on a per-app basis. For an author, there are two places to set minimum and maximum unRaid versions: - Within the plugin itself. This will prevent the plugin from installing / updating on incompatible versions - Within the xml for CA. This will prevent CA from displaying the app itself in any of its lists (under normal circumstances). The plugin manager (dynamix) and FCP both just do the check to see if an update is actually available. Neither one of them actually check if the plugin is compatible or not. (As its not really feasible for them to do that short of actually installing the update. Here's what I would do in your situation: - Disable the plugin notification within Settings - Notifications. Now dynamix will never check for (and notify you) of any updates available - Make sure that CA AutoUpdate is installed - Set it up accordingly to how you want it done. You don't need to have ANY plugins set to auto update if you don't want it to. - Set the Frequency to check for updates to be something other than disabled (daily is good) - Now AutoUpdate will check for updates, but will only install what you want (if any). Note that AutoUpdate never sends out a notification that an update is available -> only if it installs one (selectable) - Make sure that Fix Common Problems is installed - When it sends out a notification for Preclear telling you that an update is available for it, Click on the Ignore button. - Also click ignore when FCP states that Plugin Update check is not enabled Now, you will get notifications for any/all plugins having updates available with the exception of Preclear.

Personally I'm one of the vm guys. I run an openelec vm on my POS secondary sever accessible for maintenance purposes via vnc that does everything on a schedule. Problem with Kodi headless is that it's a royal pain to add in additional scrapers etc to it. Sent from my LG-D852 using Tapatalk

No clue At all unfortunately. I've never seen the need to do any post processing at all. But completely sight unseen I would guess the script is referring to localhost instead of the url of the server somewhere Sent from my LG-D852 using Tapatalk

Some controllers pause all activity to drives connected to them when it has to spin up another drive. If this is the case, then the stream(s) should continue when the file begins to actually write.

Change the host mapping of /downloads to match exactly the host mapping of /downloads that you have on nzbGet. You should also make the same change on sonarr. It will work better and won't require you to use drone factory to import the files. (ie if you turn off drone factory you'll see the exact same errors in sonarr) Sent from my LG-D852 using Tapatalk

Yes. chmod +x /mnt/user/appdataShare/sab'sConfigFolder/autoProcessTV/sabToSickBeard.py Unless there's another underlying reason for the error. I'm just going by what the error says -> I don't use sab

You would need to set the script to be executable from the command line Something like this: chmod +x /mnt/user/appdata/sabnzbd/autoProcessTV/sabToSickBeard.py (Change the actual path to suit)

What jonathanm was talking about was that the download mapping that you have on the d/l client has to be 100% identical to the download mapping that you've added to radarr. Both the container path and the host path. See the docker FAQ entry on linking containers

Whenever that supposed problem comes up, I bug everyone to post exactly how to reproduce, and no one ever can. During 6.2 Beta days, Tom was very quick to fix any issues that docker container's appdata existing on user shares instead of disk shares. To each their own though. The important thing is that the app runs correctly...

- Updated to properly detect when a port has been opened prior to proceded - Side benefit is that now the port detection can be from any server (or if you happen to have your docker container arranged such that each has a separate IP) - The plugin will default to what it believes is your local IP address, but I am unable to test in a bonded environment, so confirm the value first.

I run both of those with zero issues and all links work perfectly. You just can't Willy nilly switch between the two different methods Sent from my LG-D852 using Tapatalk

You should make it user adjustable.With any number of plugins (Notably Dynamix FIP) all trying to have watches, whatever value you set may always be too low, especially on large, complex structures.

Actually though in further testing it doesn't quite work as docker automatically makes the port available as soon as the port is mapped. Tonight's update changes the detection method and also allows for the port checked to be on a different host Sent from my LG-D852 using Tapatalk

You really should create a new thread where more eyes will see it, and the entire diagnostics file as there may be other issues that led up to the call trace

Yes, you will. Ideally, put FCP into troubleshooting mode so that if the mce error causes a crash you'll still have the info. You are going to have to reboot to clear out the mce error (if you hit ignore, then you're going to have to re-add it at the bottom of the screen) Then after the next mce error, go to tools - diagnostics and post up the file that's downloaded.

Wasn't really an uninstall. My server just decided it doesn't want to reliably boot 6.2+ anymore. Seems to be some problem with SuperMicro motherboards and/or Xeon E3-1230's. I'll need to check and see if there are any other plugins installed that won't run on 6.1.9. Ah That explains everything...

No issues with using /mnt/user/appdata vs /mnt/cache/appdata. You *may* however run into trouble if the same appdata was previously accessed via /mnt/cache/appdata instead of /mnt/user/appdata (or vice versa) My philosophy is to always use user shares for appdata, and set them to be cache: prefer though. (I actually don't have any cache only shares at all) My reasoning is that I would prefer in the case of the cache drive becoming completely full for all of my applications to still remain operational, which they will if using prefer. When set to only, the apps may fail

Is there still a folder on the flash drive /config/plugins/ca.update.applications with .cron files in there? Looks like that's it. Should I move it to "Removed Plugins"? You can just delete the folder followed by either a reboot or /usr/local/sbin/update_cron Don't know why its still there after an uninstall though. It removes that folder on both my systems

Is there still a folder on the flash drive /config/plugins/ca.update.applications with .cron files in there?

This is odds on why you're seeing the error: http://lime-technology.com/forum/index.php?topic=44989.msg541991#msg541991 You installed and subsequently removed the Dynamix File Integrity plugin.

There's a bug in the install / removal routine During installation, the plugin tries to install inotifytools (which comes with stock 6.3+). It skips the package because it's already installed on 6.3. Wouldn't it be better to do a conditional check on the installation rather than just skipping the install? (IE: if unRaid up's the version later on, FIP will wind up installing an old version unless you also update the plugin) This leads to the second, more serious issue. During plugin removal, the inotifytools package is removed, with potentially disastrous effects for anything else that might be using it, since the plugin removal is effectively removing a stock OS feature.

I don't use the app, but I will say that since its moving from /input to /output, it will always do a copy / delete because they are different mount points and that's just how every OS in the world works