BRiT

There is also a NUT v2 plugin that replaces APC Ups Daemon. That supports a different set of hardware ups models.

Still doesn't build correctly. 🤣 Or so I assume until there new version shows up.

Nothing. If you must, setup your own VPN into your home network and use that to spring board to your other servers or directly to your server. The latest RCs include WireGuard support which is new and exciting and allegedly easy to setup.

According to your diagnostic and "df", You do not have a cache disk, why are you using /mnt/cache/ in your mappings?

Oh yeah, as much as the Pi's are nifty, they're still a bit anemic on the CPU front compared to an unRaid Server. I don't know exactly how taxing running DVR engines are or what the breaking point is on Pi, as to how much it can support. Make sure the Pi is also on a UPS so you won't get glitches on recordings or minutes of downtime from rebooting. The last time I dealt with Pi's they took forever.

I would hope not, as RC7 is inevitable and should be soon.

As he said, you wont need to have drivers installed on unRaid.

Just noticed that some artwork downloads using V3 API even through MediaCenter Master is not working. The metadata scraping is working fine though. https://forums.thetvdb.com/viewtopic.php?f=122&t=60173&sid=b494805077d03d65a4fb1fa52cf05f94 1:57 PM :: tv db Updated base metadata for this show 1:57 PM :: tv db Fetching data for season 1, episode 4 1:57 PM :: tv db "If You Don't Like My Story, Write Your Own" 1:57 PM :: tv db Fetching season 1, episode 4 thumbnail... 1:57 PM :: tv db error downloading: https://artworks.thetvdb.com/banners/episodes/360733/7398586.jpg

Proper bug report is already posted here:

It's a bit of an upfront cost, but it pays for itself from ease of use and free of hassles by not requiring custom kernels if you switch over to using a network-based tuners such as HDHomeRun.

You won't be able to use that at all and will need to get one that has consistent GUIDs.

Run at least SMART short tests on all drives, to at least rule out drives from being the cause. Some of your drives report they never had any tests run on them and other drives have been on thousands of hours since the last test.

Others have identified using BTRFS with Encyption as a common cause of excessive writes.

Probably will be alright as /mnt/disk# maps to /dev/md# . Make sure it's not using /dev/sd##

There's no OOM in the latest diagnostics. Why do you think you have a problem? From memory.txt, you're fine as you have 8 Gi used for cache and buffers with 7 Gi available. total used free shared buff/cache available Mem: 31Gi 22Gi 510Mi 1.0Gi 8.2Gi 7.2Gi Swap: 0B 0B 0B Total: 31Gi 22Gi 510Mi But if you want to know what seems to be using memory, looking at Ram Usage Virtual Size (VSS) just to put things in some sort of order according to ps.txt : 31,143,876 unifi-video 11,762,276 java ace 8,915,368 java hydra2 7,817,608 java airsonic 5,942,100 jellyfin 4,101,284 emby 3,964,556 plex 3,661,308 jackett 3,277,708 evostreamms 3,125,192 Radarr 2,537,116 SABnzbd 2,359,536 mysql 1,728,220 Sonarr 1,720,208 plex plugins 1,641,704 lidarr 1,328,884 bitwarden

TheTVDB switched all of their APIs over to V3, so hopefully Plex can handle V3 of the APIs instead of possibly using V2. Switching over to V3 on MediaCenterMaster fixed it for that program. I think Plex needs the same thing as well. https://forums.thetvdb.com/viewtopic.php?f=122&t=60034

Yeah, I meant Half of Half. Yeah, that's it!

Out of sick curiosity, how does it perform with Threads=4 and CPU=Half ?

Only mentioned so that its understandable as to why one would run across those statements and why they may be confusing but that's only if you ignore the date and time of the statements.

Yes. unRAID runs from RAM and is recreated upon each and every reboot. To make things persistent you would need to use CA User Scripts plugin and have the steps you need to do in your own custom script or put those commands in the "go" file. Using CA User Scripts is the better approach.

Your network issue is the least of your concerns. You have some sort of hardware issues with your drives or controllers, as evident by just a minor snippet from your syslog with different devices. Nov 10 01:55:09 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 01:55:09 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 01:55:09 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(0000000087ecd861) Nov 10 01:55:09 UnRAID kernel: sd 10:0:0:0: Power-on or device reset occurred Nov 10 01:55:09 UnRAID kernel: repair_io_failure: 80 callbacks suppressed Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019721216 (dev /dev/sdk1 sector 675100992) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019688448 (dev /dev/sdk1 sector 675100928) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019692544 (dev /dev/sdk1 sector 675100936) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019696640 (dev /dev/sdk1 sector 675100944) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019700736 (dev /dev/sdk1 sector 675100952) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019708928 (dev /dev/sdk1 sector 675100968) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019713024 (dev /dev/sdk1 sector 675100976) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019704832 (dev /dev/sdk1 sector 675100960) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2017345536 (dev /dev/sdk1 sector 675096352) Nov 10 01:55:09 UnRAID kernel: BTRFS info (device sdb1): read error corrected: ino 72659949 off 2019717120 (dev /dev/sdk1 sector 675100984) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(00000000a094335d) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3132 CDB: opcode=0x2a 2a 00 08 ae 28 40 00 04 80 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(00000000a094335d) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(00000000022195f4) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3131 CDB: opcode=0x2a 2a 00 08 ae 22 40 00 06 00 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(00000000022195f4) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(000000005160c730) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3130 CDB: opcode=0x2a 2a 00 08 ae 1e 40 00 04 00 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(000000005160c730) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(000000007b9169b7) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3129 CDB: opcode=0x2a 2a 00 08 ae 1a 40 00 04 00 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(000000007b9169b7) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(00000000a0c0c721) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3128 CDB: opcode=0x2a 2a 00 08 ae 16 40 00 04 00 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2) Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: enclosure logical id(0x500605b00606fa40), slot(1) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: task abort: SUCCESS scmd(00000000a0c0c721) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: attempting task abort! scmd(0000000030675ffb) Nov 10 07:08:05 UnRAID kernel: sd 10:0:0:0: [sdk] tag#3127 CDB: opcode=0x2a 2a 00 08 ae 12 40 00 04 00 00 Nov 10 07:08:05 UnRAID kernel: scsi target10:0:0: handle(0x0009), sas_address(0x4433221102000000), phy(2)

Both are true. It depends on which versions you're talking about.

Dockers don't use SMB / CIF, unless you're accessing them from an entirely different system.

Could manually rename that VMs disk images which should prevent it from starting.

Report by other users on this: I dont use BTRFS so can't speak as to why it seems bugged in this situation. Just passing on what others have found.