IamSpartacus

Two (main/backup) 80TB servers that backup daily offsite.

Is there a reason why my FANS 1-4 are all grouped together and there is no FAN 5 in my Fan Settings? I've got the latest BIOS and IPMI BMC for my board (https://www.supermicro.com/products/motherboard/Xeon/C600/X10SRM-F.cfm).

I just wound up connecting via USB since my UPS is right next to my server anyway. Wasn't worth the hassle.

I dont spin my drives down and this plugin detects that all 6 of my data drives are spun down. Bit I guess for me it's not a big deal because since I dont spin my drives down I can just set turbo write as the default.

I see this. Might be new view features in 6.7RC.

I'm just showing the RAM constantly creeping up towards 4GB in Advanced Docker settings. Then I keep seeing this in my syslog: Feb 25 09:38:31 SPE-UNRAID01 kernel: Task in /docker/55b2e60f9f27f0028b26ff6f2afd34d31c045f1660d64d530ff2622a795f96cc killed as a result of limit of /docker/55b2e60f9f27f0028b26ff6f2afd34d31c045f1660d64d530ff2622a795f96cc Feb 25 09:38:31 SPE-UNRAID01 kernel: memory: usage 4194304kB, limit 4194304kB, failcnt 234151298 Feb 25 09:38:31 SPE-UNRAID01 kernel: memory+swap: usage 4194304kB, limit 8388608kB, failcnt 0 Feb 25 09:38:31 SPE-UNRAID01 kernel: kmem: usage 47156kB, limit 9007199254740988kB, failcnt 0 Feb 25 09:38:31 SPE-UNRAID01 kernel: Memory cgroup stats for /docker/55b2e60f9f27f0028b26ff6f2afd34d31c045f1660d64d530ff2622a795f96cc: cache:12772KB rss:4133200KB rss_huge:1951744KB shmem:3480KB mapped_file:396KB dirty:396KB writeback:132KB swap:0KB inactive_anon:3928KB active_anon:4134452KB inactive_file:4896KB active_file:1180KB unevictable:0KB Feb 25 09:38:31 SPE-UNRAID01 kernel: Tasks state (memory values in pages): Feb 25 09:38:31 SPE-UNRAID01 kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Feb 25 09:38:31 SPE-UNRAID01 kernel: [ 32436] 0 32436 5840 81 81920 0 0 run.sh Feb 25 09:38:31 SPE-UNRAID01 kernel: [ 32578] 0 32578 4314 42 73728 0 0 jsvc Feb 25 09:38:31 SPE-UNRAID01 kernel: [ 8499] 99 8499 7912541 1030559 10633216 0 0 jsvc Feb 25 09:38:31 SPE-UNRAID01 kernel: Memory cgroup out of memory: Kill process 8499 (jsvc) score 985 or sacrifice child Feb 25 09:38:31 SPE-UNRAID01 kernel: Killed process 8499 (jsvc) total-vm:31650164kB, anon-rss:4123796kB, file-rss:0kB, shmem-rss:0kB It's been doing this for a few days and only reboots fix it (until it reaches the RAM limit again). For now I've rolled back to 3.9. Lots of people complaining about memory leaks in 3.10 on the Ubiquiti forums.

Does anyone know if it's possible to downgrade back to 3.9? My 3.10.x container is unsable because of the memory leak as it keeps hitting my defined 4GB ram limit and then crashing. It's unusable at this point.

Looks like there is a major memory leak when upgrading as well. Looks like a fresh install is the only thing that fixes it according to the forums. As of right now with my container having been running for about 12 hours now since upgrading and it's using just about 14GB of RAM. Not good. I've since limited my containers RAM usage limit to 4GB.

I'm guessing this is why everyone who upgraded had issues? https://community.ubnt.com/t5/UniFi-Video-Blog/UniFi-Video-3-10-1-Full-Release/ba-p/2674717

It might support it through snmp. Should I be able to enter my UPS' IP where it shows 127.0.0.1? My server doesn't seem to allow any input there.

Does this plugin only support USB connected UPS'? I have an RMCARD203 network card in my Cyberpower OL1000RTXL2U UPS and was hoping there was a way to manage it through Unraid.

So based on the latest comments on this thread I'm going to assume it's NOT safe to update my Unifi Video container.

I believe that is correct, it should be UDP and I manually changed it before adding this new container. LSIO, this is some great work. You guys are killers. I too am sticking with 5.9.x as 5.10.x looks like a $hit show thus far.

After doing a hardware upgrade and subsequent restore of all my docker appdata, I'm having the EAC3 issue again where no files with EAC3 audio will playback unless I delete the Codecs folder. I remember this being an issue a year or two ago and I had to delete this folder after each PMS upgrade to get EAC3 files to work again. Does anyone know a permanent fix for this? I can't remeber what I did to get this working long term.

Backup/Restore Appdata plugin.

I had to restore my appdata using the backup/restore plugin and after doing so my letsencrypt container isn't working. I'm getting the following message over and over in the log: nginx: [emerg] PEM_read_bio_X509_AUX("/config/keys/letsencrypt/fullchain.pem") failed (SSL: error:09FFF06C:PEM routines:CRYPTO_internal:no start line:Expecting: TRUSTED CERTIFICATE) EDIT: Recreating the container fixed the issue.

Anyone running a Mac Mojave VM on the latest RC? Ever since I upgraded to 6.7RC* and I go to boot my Mac OS Mojave VM it just hangs at the Apple icon and never gets past it.

This plugin doesn't work for me either. It also is reading that 4 drives are spun down and all 8 of my drives are on the same LSI3008 controller and set to never spin down.

Thanks, I found AVSub that does the trick. But yes you are right you can't separate podcasts but no big deal. I just wanted native podcast support which the app list doesn't really mention but I'm all set.

Doeas anyone know of an iOS app that has podcast support similarly to how DSub does on Android? Trying to find an app for my wife's phone so she can manage her own podcasts without having to download them to my music library.

@limetech Ok I tested this again last night and got similar yet slightly different results. My CPU was basically idle (less than 10% usage as I had just 2 direct plays going in Plex). As soon as I kicked off the mover, within a few seconds the CPU usage jumped up over 70% as you can see from Screenshot #1. This stayed the case for about 4-5 minutes and during this time my Plex Direct plays stopped as soon as the buffers on my Shield TV's ran out. Screenshot #2 shows that virtually nothing is going on in the system that would explain the CPU usage showing as being so high at this time. The CPU usage (or lack there of) in htop not matching up what's being shown in the webUI is very strange to me. After 4-5 minutes, the CPU returned to a normal state for a few minutes or so and I was able to resume my Plex direct plays. The mover was still going at this point and would continue for another 10-15 minutes. Then, the CPU usage jumped up again (Screenshot#3). This again made Plex unresponsive. However, this time when I opened htop (sorry I didn't get a screenshot of this) I saw two Plex processes consuming a lot of the CPU and this continued for 10+ minutes. I had to actually restart the Plex docker to regain usage of the server again. I copied my Plex logs folder at this time so I could go through them and determine what was going on in Plex at that time. I'm not really sure what I'm looking for but I will try to narrow it down. I don't know why the mover starting to move files initially would be causing the CPU usage to be so high. I've got an 8C/16t CPU (Xeon D-1541) so the mover should not be taxing it so much. It then appears that the moving of the files is kicking some kind of process off in Plex that causes Plex to freak out. The Plex piece I'll have to investigate on my own because none of this is really adding up. I don't see why simply moving files around in Unraid would cause Plex to do anything at all. The WebGUI never becomes unresponsive during any of this and the syslog shows nothing other than the mover logs.

Yea as @trurl said I'm not sure what you mean you don't use the appdata share. I use it i just purposely placed it on an unassigned disk and not my cache drive. This is why I'm quite confused about what's causing my issue.

From the lack of response I take it this is not common