flaggart

I just used the velcro straps that were already there - I think they are supposed to be for cable management, it wasn't the greatest arrangement. I just settled for one drive there.

It is a: OWC OWCMM52T35 - OWC Multi-Mount 3.5 to 5.25 Bracket I have also used a "Nexus DoubleTwin" for the same purpose.

Hi, Since unraid v 6.6.1 I have been having issues with auto updating of the system and plugins. This was because wget was unable to verify certificates, due to conflicting versions of openssl. I think this is because your plugin installs libssl1-1.1.0g. Unraid syslog shows "OpenSSL version mismatch. Built against 1010100f, you have 1010007f#015" Uninstalling the plugin resolved the issue. I have started using a tvheadend docker container, but if you still have the will/interest to maintain this, I would prefer the plugin. Thanks.

After updating to 6.4 initially everything is OK, however after a while all disks attached to my SuperMicro AOC-SAS2LP-MV8 slow massively. Disks attached to the motherboard directly are not affected. The worst affected disks slow to 2 MB/sec read. The least affected slow to 40 MB/sec. After rebooting, everything is again OK for a short while before the problem returns. I know this HBA card is listed as potentially having issues - specifically random parity errors upon reboot - but I have not observed this issue and so have continued to use it. I am wondering, has support for this card been removed, or is there an issue? Logs attached. bigbox-diagnostics-20180116-1939.zip

There is a similar deal in the UK for a card with the same chipset. Reduced from £217 to £100 (confirmed by Camelizer which says the previous low was £180 in October). May be of use to some of you - I have just ordered. https://www.amazon.co.uk/gp/product/B0085FT2JC/ref=od_aui_detailpages00?ie=UTF8&psc=1

Hi all, Update went smoothly however syslog is now spammed with the following: Jan 15 07:17:01 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [753ab0] Jan 15 07:17:01 Tower kernel: SQUASHFS error: Unable to read page, block 753ab0, size f38 Jan 15 07:17:01 Tower kernel: SQUASHFS error: Unable to read fragment cache entry [7549e8] Jan 15 07:17:01 Tower kernel: SQUASHFS error: Unable to read page, block 7549e8, size 38fc

Same issue here. I had to roll back to 4.2.3 - I had not updated for a while. Thanks for your efforts, much appreciated.

https://wiki.lime-technology.com/Hardware_Compatibility#PCI_SATA_Controllers

Sounds like Guacamole VNC/RDP web proxy - http://guacamole.incubator.apache.org/

Hi all, I have been unable to get PWM fan control working on a Supermicro C7Q67. This board has a Nuvoton NCT6776F, which is detected when running sensors_detect. However after "modprobe nct6775" the output of "sensors" only shows coretemp. Logfile attached - would be grateful for any support or suggestions. sensors_detect.txt

Parity drive is only needed to recreate data from the missing drive. Perhaps everything that you are doing only needs data from the drives which are present. This is not like RAID5 where the data is striped across all disks, in which case all disks are spun up whenever accessing any data.

I have an issue with tvheadend randomly stopping. Here is what seems to be the relevant log entry: Sep 15 04:32:49 TOWER kernel: Out of memory: Kill process 31524 (tvheadend) score 776 or sacrifice child Sep 15 04:32:49 TOWER kernel: Killed process 31524 (tvheadend) total-vm:14558828kB, anon-rss:13054820kB, file-rss:5664kB Sep 15 04:32:49 TOWER kernel: mc invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Sep 15 04:32:49 TOWER kernel: mc cpuset=/ mems_allowed=0 Sep 15 04:32:49 TOWER kernel: CPU: 5 PID: 6006 Comm: mc Tainted: P W O 4.1.15-unRAID #1 Sep 15 04:32:49 TOWER kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B75M-ITX, BIOS P1.90 07/17/2013 Sep 15 04:32:49 TOWER kernel: 0000000000000000 ffff880110bb79e8 ffffffff815f8950 0000000000007c48 Sep 15 04:32:49 TOWER kernel: ffff8803d9508000 ffff880110bb7a98 ffffffff815f4ecc ffff880110bb7a48 Sep 15 04:32:49 TOWER kernel: ffffffff810f6ce9 ffff880014007000 01ff880110bb7a08 ffff880110bb7a48 Sep 15 04:32:49 TOWER kernel: Call Trace: Sep 15 04:32:49 TOWER kernel: [<ffffffff815f8950>] dump_stack+0x4c/0x6e Sep 15 04:32:49 TOWER kernel: [<ffffffff815f4ecc>] dump_header+0x7a/0x20b Sep 15 04:32:49 TOWER kernel: [<ffffffff810f6ce9>] ? mem_cgroup_iter+0x2fd/0x3fb Sep 15 04:32:49 TOWER kernel: [<ffffffff810fac63>] ? vmpressure+0x1c/0x6f Sep 15 04:32:49 TOWER kernel: [<ffffffff81355273>] ? ___ratelimit+0xcf/0xe0 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b3c52>] oom_kill_process+0xb7/0x37b Sep 15 04:32:49 TOWER kernel: [<ffffffff810b3957>] ? oom_badness+0xb6/0x100 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b43a7>] __out_of_memory+0x441/0x463 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b4508>] out_of_memory+0x4f/0x66 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b850c>] __alloc_pages_nodemask+0x722/0x7b6 Sep 15 04:32:49 TOWER kernel: [<ffffffff810e4a14>] alloc_pages_current+0xb4/0xd5 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b1a5e>] __page_cache_alloc+0x88/0x95 Sep 15 04:32:49 TOWER kernel: [<ffffffff810b25d5>] generic_file_read_iter+0x32e/0x551 Sep 15 04:32:49 TOWER kernel: [<ffffffff810fd847>] __vfs_read+0x89/0xad Sep 15 04:32:49 TOWER kernel: [<ffffffff810fdd33>] vfs_read+0x84/0x11d Sep 15 04:32:49 TOWER kernel: [<ffffffff810fe543>] SyS_read+0x42/0x86 Sep 15 04:32:49 TOWER kernel: [<ffffffff815fe06e>] system_call_fastpath+0x12/0x71 Sep 15 04:32:49 TOWER kernel: Mem-Info: Sep 15 04:32:49 TOWER kernel: active_anon:3730744 inactive_anon:108262 isolated_anon:0 Sep 15 04:32:49 TOWER kernel: active_file:9983 inactive_file:10619 isolated_file:290 Sep 15 04:32:49 TOWER kernel: unevictable:0 dirty:4528 writeback:831 unstable:0 Sep 15 04:32:49 TOWER kernel: slab_reclaimable:96842 slab_unreclaimable:29449 Sep 15 04:32:49 TOWER kernel: mapped:26683 shmem:205360 pagetables:12848 bounce:0 Sep 15 04:32:49 TOWER kernel: free:20239 free_pcp:0 free_cma:0 Sep 15 04:32:49 TOWER kernel: Node 0 DMA free:15104kB min:12kB low:12kB high:16kB active_anon:64kB inactive_anon:176kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15984kB managed:15360kB mlocked:0kB dirty:0kB writeback:0kB mapped:64kB shmem:240kB slab_reclaimable:16kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Sep 15 04:32:49 TOWER kernel: lowmem_reserve[]: 0 3423 15939 15939 Sep 15 04:32:49 TOWER kernel: Node 0 DMA32 free:53496kB min:3444kB low:4304kB high:5164kB active_anon:3051428kB inactive_anon:102404kB active_file:10344kB inactive_file:11520kB unevictable:0kB isolated(anon):0kB isolated(file):200kB present:3581300kB managed:3506316kB mlocked:0kB dirty:5788kB writeback:680kB mapped:22072kB shmem:182956kB slab_reclaimable:175688kB slab_unreclaimable:28640kB kernel_stack:4208kB pagetables:11936kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:144228 all_unreclaimable? yes Sep 15 04:32:49 TOWER kernel: lowmem_reserve[]: 0 0 12516 12516 Sep 15 04:32:49 TOWER kernel: Node 0 Normal free:12356kB min:12600kB low:15748kB high:18900kB active_anon:11871484kB inactive_anon:330468kB active_file:29696kB inactive_file:30816kB unevictable:0kB isolated(anon):0kB isolated(file):832kB present:13080576kB managed:12816552kB mlocked:0kB dirty:12324kB writeback:2644kB mapped:84596kB shmem:638244kB slab_reclaimable:211664kB slab_unreclaimable:89156kB kernel_stack:8048kB pagetables:39456kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:433692 all_unreclaimable? yes Sep 15 04:32:49 TOWER kernel: lowmem_reserve[]: 0 0 0 0 Sep 15 04:32:49 TOWER kernel: Node 0 DMA: 0*4kB 0*8kB 2*16kB (EM) 1*32kB (E) 1*64kB (E) 1*128kB (E) 2*256kB (EM) 2*512kB (EM) 3*1024kB (UEM) 3*2048kB (UEM) 1*4096kB (R) = 15104kB Sep 15 04:32:49 TOWER kernel: Node 0 DMA32: 2868*4kB (UER) 3174*8kB (UEMR) 1000*16kB (UEMR) 5*32kB (R) 2*64kB (R) 3*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 53792kB Sep 15 04:32:49 TOWER kernel: Node 0 Normal: 2815*4kB (UEM) 58*8kB (EM) 32*16kB (R) 8*32kB (R) 2*64kB (R) 3*128kB (R) 2*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13516kB Sep 15 04:32:49 TOWER kernel: 226405 total pagecache pages Sep 15 04:32:49 TOWER kernel: 0 pages in swap cache Sep 15 04:32:49 TOWER kernel: Swap cache stats: add 0, delete 0, find 0/0 Sep 15 04:32:49 TOWER kernel: Free swap = 0kB Sep 15 04:32:49 TOWER kernel: Total swap = 0kB Sep 15 04:32:49 TOWER kernel: 4169465 pages RAM Sep 15 04:32:49 TOWER kernel: 0 pages HighMem/MovableOnly Sep 15 04:32:49 TOWER kernel: 84908 pages reserved Sep 15 04:32:49 TOWER kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name Sep 15 04:32:49 TOWER kernel: [ 1045] 0 1045 5395 598 15 3 0 -1000 udevd Sep 15 04:32:49 TOWER kernel: [ 1299] 0 1299 58398 850 25 3 0 0 rsyslogd Sep 15 04:32:49 TOWER kernel: [ 1572] 0 1572 1671 452 8 3 0 0 dhcpcd Sep 15 04:32:49 TOWER kernel: [ 1582] 1 1582 1714 369 9 3 0 0 rpc.portmap Sep 15 04:32:49 TOWER kernel: [ 1586] 32 1586 3209 448 11 3 0 0 rpc.statd Sep 15 04:32:49 TOWER kernel: [ 1596] 0 1596 1615 435 8 3 0 0 inetd <snip> Sep 15 04:32:49 TOWER kernel: [31386] 0 31386 11038 165 25 4 0 0 ssh Sep 15 04:32:49 TOWER kernel: [31395] 0 31395 11038 166 25 3 0 0 ssh Sep 15 04:32:49 TOWER kernel: [32019] 999 32019 243894 25320 123 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [ 3295] 999 3295 297309 20457 123 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [ 3410] 999 3410 242943 20734 117 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [ 4908] 999 4908 261243 19817 117 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [32178] 999 32178 397437 18226 126 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [32181] 999 32181 315003 16144 115 4 0 0 Plex Script Hos Sep 15 04:32:49 TOWER kernel: [ 8082] 0 8082 1091 189 7 3 0 0 sleep Sep 15 04:32:49 TOWER kernel: [ 8129] 0 8129 2159 216 9 3 0 0 timeout Sep 15 04:32:49 TOWER kernel: [ 8130] 0 8130 2974 260 10 3 0 0 find Sep 15 04:32:49 TOWER kernel: [ 8149] 0 8149 1091 158 7 3 0 0 sleep Sep 15 04:32:49 TOWER kernel: Out of memory: Kill process 31526 (linuxdvb_fronte) score 776 or sacrifice child Sep 15 04:32:49 TOWER kernel: Killed process 31572 (mpegts_input_th) total-vm:14558828kB, anon-rss:13055084kB, file-rss:6388kB There is 16gb RAM in the server so with no VMs running so I wouldn't have expected to be out of memory...

Not sure it is normal unless you have a huge library. For comparison I have: Movies: 2186 Tv: 13099 Plex takes up 17G. I do not have a "library" subdir - are you running an older version of the plugin?

It would be sensible to install an Nginx docker and configure it as a reverse proxy so that you can access Guacamole via HTTPS: https://guacamole.incubator.apache.org/doc/gug/proxying-guacamole.html

Thanks! Fixed it.

I had this issue. Are you by any chance using an i7-2600k? If so add this to the XML, replacing the existing cpu mode section: <cpu mode='custom' match='exact'> <model fallback='forbid'>SandyBridge</model> <feature policy='disable' name='x2apic'/> </cpu>

Might be worth trying the tips on this page: http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/ In particular, deleting "dangling" images and unwanted volumes left behind after deleting containers: docker rmi $(docker images -f "dangling=true" -q) docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes

root@TOWER:~# docker stats openvpn-as Nginx ownCloud Guacamole CONTAINER CPU % MEM USAGE/LIMIT MEM % NET I/O Guacamole 4.89% 545.1 MB/16.73 GB 3.26% 608.2 MB/1.152 GB Nginx 0.04% 42.55 MB/16.73 GB 0.25% 50.43 MB/51.86 MB openvpn-as 0.08% 185.7 MB/16.73 GB 1.11% 0 B/0 B ownCloud 0.02% 112 MB/16.73 GB 0.67% 12.97 MB/41.39 MB

It seems unable to connect to the core now, where as before that part worked. Plugin "plugins/pushbullet.py" loaded. Traceback (most recent call last): File "/usr/local/emhttp/plugins/qnotify/PyQuassel/quasselbot.py", line 74, in <module> quasselClient.run() File "/usr/local/emhttp/plugins/qnotify/PyQuassel/quasselclient.py", line 269, in run self.createSession() File "/usr/local/emhttp/plugins/qnotify/PyQuassel/quasselclient.py", line 262, in createSession self.readSessionState() File "/usr/local/emhttp/plugins/qnotify/PyQuassel/quasselclient.py", line 114, in readSessionState data = self.stream.read() File "/usr/local/emhttp/plugins/qnotify/PyQuassel/qt.py", line 309, in read buf = self.device.read(4) File "/usr/local/emhttp/plugins/qnotify/PyQuassel/qt.py", line 72, in read buf = self.socket.recv(maxSize) socket.timeout: timed out

It would be nice if there was another way, as my Quassel core is on a remote machine. I rigged your plugin to connect to it through a ssh tunnel I expect this isn't your typical use-case though.

6.1.7. Yes I set Pushbullet device name. Is this a Python issue? I have 2.7.9 installed for something else.. and this needs 3.x?

When I stop this plugin from the webinterface, it spams a constant stream of "y y y y y y y y y y y y y y y y y....." which continues until I close the tab and re-open it, at which point tvheadend has stopped. The same thing happens when I stop the array and I have to SSH in and "killall yes" then wait a few mins for it to recover. Really annoying!

Installed, and it connects to quassel core OK. However, when it detects a keyword: Error while calling plugin_pushbullet.onMessageRecieved Traceback (most recent call last): File "/usr/local/emhttp/plugins/qnotify/PyQuassel/quasselbot.py", line 45, in pluginCall fn(self, *args) File "plugins/pushbullet.py", line 37, in onMessageRecieved device = pushNotification.get_device(nickname=bot.config.pushbulletDeviceName) File "/usr/local/emhttp/plugins/qnotify/PyQuassel/pushbullet.py", line 50, in get_device device_list = self.get_device_list() File "/usr/local/emhttp/plugins/qnotify/PyQuassel/pushbullet.py", line 46, in get_device_list data = self.session.get('https://api.pushbullet.com/v2/devices') File "/usr/local/emhttp/plugins/qnotify/PyQuassel/pushbullet.py", line 26, in get return self.request(*args, method='GET', **kwargs) File "/usr/local/emhttp/plugins/qnotify/PyQuassel/pushbullet.py", line 21, in request with urllib.request.urlopen(req) as res: File "/usr/lib64/python3.5/urllib/request.py", line 162, in urlopen return opener.open(url, data, timeout) File "/usr/lib64/python3.5/urllib/request.py", line 465, in open response = self._open(req, data) File "/usr/lib64/python3.5/urllib/request.py", line 488, in _open 'unknown_open', req) File "/usr/lib64/python3.5/urllib/request.py", line 443, in _call_chain result = func(*args) File "/usr/lib64/python3.5/urllib/request.py", line 1310, in unknown_open raise URLError('unknown url type: %s' % type) urllib.error.URLError: <urlopen error unknown url type: https>

EVO 840 I don't think unraid did a "non quick format" as it completed in seconds. Yet the performance increase was also instant - back to maxing out gigabit ethernet before I issued a TRIM command. Would this suggest there was more wrong with the original ReiserFS filesytsem than simply needing to be TRIMed?

In my case I had exhausted all other options including NIC offloading on the Windows box the screenshots were from. I figured others with ReiserFS cache drives may be in the same situation, and this post was designed to help people avoid irreparable damage. Perhaps unraid webinterface could mention that ReiserFS is not a suitable filesystem for cache disks.