Michael_P

Right, but disabling the ones your soundbar doesn't support might keep the shield from 'hunting'

Have you tried only enabling the codecs your soundbar supports in the shield tv audio settings? Auto mode can be finicky sometimes

system/ps.txt --setenv VPN_USER ******** --setenv VPN_PASS ********

Kill it, make sure your server isn't exposed to the internet, check your go file and extras folder on your flash drive for anything weird. And your VPN credentials are exposed in your diagnostics, you should edit the top post to remove it and change your VPN password as a matter of course. @limetech should really start thinking about obfuscating that.

Probably compromised- xmrig has it pegged

Then it could have been an anomaly, just reboot and ignore it. If it happens again, investigate further or limit the RAM to that container.

Looks like it was probably SABnzbd/Headphones - it only happened twice, on the 24th and 25th so if you were playing around with it on those days, then there's your answer. FCP will continue to warn you until you reboot and the log is cleared.

Easy - UrBackup https://www.urbackup.org/

Make sure you have sufficient power to each drive - no more than 4 drives per molex power connector, and preferably split across multiple cables from the PSU Make sure your HBA is sufficiently cooled Make sure your cables are connected properly, and not squeezed together so as to introduce crosstalk Try a different slot on the motherboard, or replace the HBA.

Your GT1030 isn't doing anything but wasting power, the GT line doesn't have any nvenc encoders (only the GTX does) https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

I should mention, if you're using it at work, on a work device, to bypass their internal restrictions - it would be frowned upon

Nope, use it as much as you like. I use pfsense and openvpn but it's same concept, so I can block ads on my mobile while out and about

That's precisely what it's doing Because all of your traffic while the VPN is connected is going through the VPN and back out to the internet at large through your home connection. If you are trying to keep your mobile traffic obscured from your mobile ISP, or your work's network in the case you've described above, then job done - but your home ISP will still see the traffic. You'll need an external provider to mask it.

The local VPN is for local access, the only 'prying eyes' would be yours. If you want general online privacy, you'll need an external provider to shield internet traffic.

Don't cheap out on storage, that's my philosophy. Even with good backups, it's just less of a pain when you don't have to chase gremlins.

It's safe to ignore

Power supply would be my first suspect - bent CPU LGA pin would be my second

Be a lot easier if you just kept all that stuff on an encrypted drive outside of the array

Encrypted drive in unassigned devices, remove the key after mounting, and a script to reboot the server akin to what @JonathanM suggested. No file recovery, and no chance that rm gets interrupted. And the bonus that if you're indisposed but not dead, you can just remount the encrypted drive and carry on with your spy shit.

Each data drive has its own file system so just put it in your new system.

And whatever you do, don't charge for access - that's criminal copyright infringement with big boy jail time.

Safe to ignore

Still looks like the kernel killing it because it thinks it's about to crash due to running OOM In any case, you know what caused it - and if you want force it to use docker's killer, add the --oom-kill-disable option - but use with care as the kernel will start killing system processes if it goes OOM again

If Docker is enforcing the limit, it won't (or at least shouldn't) show in the system log. If the OOM reaper is invoked, it will

The system ran OOM and the reaper killed the process which it believed was the culprit. Either your limit wasn't respected, or it's not working correctly. FCP just scans the log and alerts when it sees 'OOM' - and it will continue to alert until the log is cleared on reboot