BRiT

Also, dvb drivers are a total mess, just look at how many different build CHMB has to do and even then there are times where updates to those drivers break existing hardware, just look at the support threads. Overall, the simplest and easiest approach forward for tuner users is to switch over to external ethernet mapped devices. All problems solved and no need for host level drivers.

Size requirements on the flash drive and how much memory it would take since its booted from ram. Up until relatively recently, unraid fit on some of the smallest flash drives.

Parity never has a filesystem format.

So intead you'd rather spend your own time, you should really place a value on your own time, and doing show will show its financially cheaper to just pick up an external dvb device.

Why is external DVB not an option?

Yes, please file a bug report, including details there and linking back to this thread, and also and include the details of using copytruncate in the config file.

Raid1 is not a backup either. You need your data offsite for it to be backup.

@bonienl there is nothing running on his unraid server. Check his diagnostics ps.txt and you'll see nothing running locally. That Plex VM is from a different server. The only thing related on this unraid server is: root 8450 0.0 0.4 1048992 69048 ? Sl 2019 11:35 /usr/bin/dockerd -p /var/run/dockerd.pid --mtu=9198 --storage-driver=btrfs --log-level=error root 8465 0.0 0.2 559724 32908 ? Ssl 2019 7:18 \_ containerd --config /var/run/docker/containerd/containerd.toml --log-level error

Maybe run the following command and see what shows up? netstat

The /system/lsof.txt file shows the following activity over SAMBA (smbd) where user mediauser has 36 file updates running over a local IPV4 connection and there's other updates happening over a local IPV6 connection: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME smbd 4446 mediauser 36u IPv4 31900225 0t0 TCP 192.168.1.25:445->192.168.1.42:64038 (ESTABLISHED) smbd 14253 root 36u IPv6 24440816 0t0 TCP [fe80::884:6cff:fe6a:c2e6]:445->[fe80::ecc6:fad3:7f63:5a0b]:51109 (ESTABLISHED) smbd 15256 root 36u IPv6 30752540 0t0 TCP [fe80::884:6cff:fe6a:c2e6]:445->[fe80::51aa:719a:4a63:f41e]:49673 (ESTABLISHED) smbd 15607 root 35u IPv6 24067072 0t0 TCP [fe80::884:6cff:fe6a:c2e6]:445->[fe80::3807:937a:de20:eb5e]:56566 (ESTABLISHED) USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 12939 0.0 0.0 52152 15188 ? Ss Jan02 0:00 /usr/sbin/smbd -D mediaus+ 4446 0.1 0.1 60616 20180 ? S Jan04 3:00 \_ /usr/sbin/smbd -D root 12942 0.0 0.0 52368 8232 ? S Jan02 0:09 \_ /usr/sbin/smbd -D root 12943 0.0 0.0 50324 7384 ? S Jan02 0:00 \_ /usr/sbin/smbd -D root 14253 0.0 0.0 52548 15040 ? S Jan02 0:00 \_ /usr/sbin/smbd -D root 15256 0.0 0.1 57504 18748 ? S Jan03 0:11 \_ /usr/sbin/smbd -D root 15607 0.0 0.1 54048 17372 ? S Jan02 0:05 \_ /usr/sbin/smbd -D

It's like /var/log/docker.log.1 was using 163.x Meg or so, if this is the filesize -- 171606437. It aligns to the Size/OFF field of the LSOF output. And you cycling docker and having freed up nearly 164 Meg aligns with this. lsof /var/log/docker.log COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME FD - File Descriptor # - The number in front of flag(s) is the file descriptor number of used by the process to associated with the file u - File open with Read and Write permission r - File open with Read permission w - File open with Write permission W - File open with Write permission and with Write Lock on entire file mem - Memory mapped file, usually for share library

And you have no way of seeing what's in /var/log/docker.log.1 ... So this is quite annoying to attempt to troubleshoot.

What is your docker.log even filled with? Doing it once will get you by your issue for now. I never said to do it randomly, nor repeatedly. You could try the following, adjust 320m to be whatever increased size you require. for your /var/log/ partition. Once you're satisfied, you can then add it to your /boot/config/go script so it happens automatically upon startup. # resize log partition mount -o remount,size=320m /var/log I use 192M on mine and here's what mine looks like: #df -h /var/log Filesystem Size Used Avail Use% Mounted on tmpfs 192M 488K 192M 1% /var/log

The other docker container: root 21735 0.1 0.0 109104 7808 ? Sl 03:36 0:39 | \_ containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/9c63bc954f1929047bfefedca0d520e92dbb1ca7dfb2e3fc61a48792a4c26aa9 -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 21752 0.0 0.0 204 4 ? Ss 03:36 0:00 | | \_ s6-svscan -t0 /var/run/s6/services root 21826 0.0 0.0 204 4 ? S 03:36 0:00 | | \_ s6-supervise s6-fdholderd root 22151 0.0 0.0 204 4 ? S 03:36 0:00 | | \_ s6-supervise embystat nobody 22159 93.3 0.3 22089576 90960 ? SLsl 03:36 313:56 | | \_ /opt/embystat/EmbyStat --no-updates

That mono process is part of Radar. root 22837 0.1 0.0 109104 7660 ? Sl 03:36 0:39 | \_ containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/7c083e04685d42459fcac88f702479ce4a413bad7e348bf06085a0650e553bdd -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc root 22876 0.0 0.0 204 4 ? Ss 03:36 0:00 | | \_ s6-svscan -t0 /var/run/s6/services root 23032 0.0 0.0 204 4 ? S 03:36 0:00 | | \_ s6-supervise s6-fdholderd root 23264 0.0 0.0 204 4 ? S 03:36 0:00 | | \_ s6-supervise radarr nobody 23267 0.9 1.2 1651200 291500 ? Ssl 03:36 3:08 | | \_ mono --debug Radarr.exe -nobrowser -data=/config

It's your dockers. Look at your ps or top reports. top - 09:12:37 up 3 days, 22:43, 0 users, load average: 2.45, 3.10, 2.79 Tasks: 422 total, 3 running, 418 sleeping, 0 stopped, 1 zombie %Cpu(s): 59.1 us, 9.1 sy, 0.0 ni, 31.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 23047.5 total, 274.2 free, 6474.9 used, 16298.4 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 15115.3 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23267 nobody 20 0 1651200 291500 28772 S 131.2 1.2 3:08.72 mono 22159 nobody 20 0 21.1g 90960 31256 S 106.2 0.4 313:56.59 EmbyStat 28177 root 20 0 904128 127168 1136 S 18.8 0.5 422:02.25 shfs 6031 root 20 0 349140 4340 3540 S 6.2 0.0 29:31.27 emhttpd 22956 nobody 20 0 45080 35656 2780 S 6.2 0.2 0:40.92 nzbget 28699 nobody 20 0 62476 21568 18028 S 6.2 0.1 173:39.48 smbd 1 root 20 0 2468 1840 1736 S 0.0 0.0 0:33.18 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.16 kthreadd

Simply stop Docker using the Web UI then start it.

Nothing standing out in the syslog in way of errors or extraneous connections. Though Currently your Handbrake process is using 1389% of your CPU while unraid is using 83%, so that's using 15 of your 16 cores. top - 19:18:05 up 1:07, 0 users, load average: 23.89, 22.70, 17.84 Tasks: 448 total, 4 running, 443 sleeping, 0 stopped, 1 zombie %Cpu(s): 5.9 us, 7.8 sy, 84.4 ni, 2.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 8033.7 total, 133.0 free, 2505.4 used, 5395.3 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 4552.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16145 root 20 0 2013344 1.5g 17572 S 1389 18.9 327:22.46 HandBrake+ 30837 root 20 0 0 0 0 R 83.3 0.0 22:38.78 unraidd0

I liked my /8/ but had to give it up for a new one.

Parity does not contain a filesystem.

I had that happen as well. Old stream was disfunctional. Oddly enough new stream works. I worked around it by deleting my custom activity stream and created a new one.

Switch over to using ethernet-based DVB/Tuning hardware. It will make things so much easier for you.

Depending on the age and health of those drives, it might be prudent to do preventative maintenance and replace the 3TB with 8TB, 10TB, or 12TB drives. Be sure to run smart tests on the drives first before looking into options of adding even more drives.

Problem begins with Disk 29 then Disk 0, reads and write issues. Dec 28 17:35:19 Void kernel: mpt2sas_cm0: log_info(0x31110d01): originator(PL), code(0x11), sub_code(0x0d01) ### [PREVIOUS LINE REPEATED 6 TIMES] ### Dec 28 17:35:19 Void kernel: sd 8:0:0:0: [sdb] tag#6204 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Dec 28 17:35:19 Void kernel: sd 8:0:0:0: [sdb] tag#6204 Sense Key : 0x2 [current] Dec 28 17:35:19 Void kernel: sd 8:0:0:0: [sdb] tag#6204 ASC=0x4 ASCQ=0x0 Dec 28 17:35:19 Void kernel: sd 8:0:0:0: [sdb] tag#6204 CDB: opcode=0x8a 8a 00 00 00 00 02 35 7e e8 c0 00 00 04 00 00 00 Dec 28 17:35:19 Void kernel: print_req_error: I/O error, dev sdb, sector 9487444160 Dec 28 17:35:19 Void kernel: md: disk29 write error, sector=9487444096

Possibly Hardware issues that you have ignored: Dec 29 15:32:04 Tower root: Fix Common Problems: Error: Machine Check Events detected on your server ** Ignored