MowMdown

Can you post your example of what you mean by "above" because my situation was appeared to be levels 4 and 5 were the issue but levels 1-2-3 seemed to work fine when split was set to level 3 (in my mind i'd consider levels 4 and 5 are "below" or deeper than level 3) I just want to get a better idea of what you found the issue to be on your end.

I don't see a variable for NVIDIA_VISIBLE_DEVICES = all nor NVIDIA_DRIVER_CAPABILITIES = all, I know you said you added them but they're not showing up here.

It shouldn't matter which plex docker you use, they should all support nvidia hardware transcoding. That's not something that is typically custom to certain versions of plex I don't think. It should just be standard across the board. I stopped using nvidia a while ago so I can't remember if you could ever run nvidia-smi inside plex container. Can you post the docker run command it's using to launch plex. Here's a clue plex can't see the card, it would show up in the dropdown. something is not passed through properly. Probably a typo somewhere I would also set this to "all" same as the other one

That's good, the only share I had set to automatic worked, the others didn't.

Well do you have a plex-pass license/subscription? without paying for it hardware encoding/decoding is not possible. when trascoding something you should check the plex playback dashboard and see if "Transcode (hw)" shows up like this example: If the "(hw)" does not appear next to the word transcode, you're not using the gpu.

Here is the relevant syslog, I found a backup copy. Everything listed as "successful" was deleted except for the appdata backup files, for whatever reason those moved properly after I made a share change to "split any directory as required" from "manual" Data share split level is "top 3" and I didn't change that. I stopped mover, excluded disk5 from all shares, I noticed parent folders started showing up on disk1 but the files themselves did not move to disk1. syslog.txt

Those messages are from the file activity plugin, not from mover or syslog. Mover was in fact operating as I was seeing "move success" messages throughout the operation. For example: mover: /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin sucesss I believe mover was moving the file from disk5 to disk5 due to it having the most free space and a "s-----31.bin.partial" file occupied the same location by evidence of the file activity log (highwater allocation selecting disk5 as the available disk to use) IMO to fix this, mover needs to have a check that it does not move the files to the same disk they currently occupy. If Im running "mover start -e disk5 |& logger &" then mover needs to exclude disk5 from it's operation.

As you may have noticed, we just fixed my xfs disk mounting issue in that other thread, those are the only diagnostics I currently have as I gave up with the mover to empty disk after I confirmed it deleted data from disk5 without moving it to the other disks. All in all Ilist about 40GB, not a major loss and I was able to recover it. Here is the scenario in which it occurred. Disks 1-4 were approximately 50%, 50%, 70% and 50% full respectively. Disk 5 was 17% full. I wanted to use mover to empty disk5 so I could convert it to parity2. All shares are set to highwater, all disks were included, nothing excluded. Mostly unraid default settings. I ran mover on disk5 to empty it, and at first I found it odd that only disk5 was being both written to and read from. I stopped mover and thought it had deleted some data. Parent folders did appear on other disks just nothing inside them. I decided to exclude disk5 from all shares and re-ran mover again, this time one of my shares respected this and the data successfully moved to disk1. my "data" share however did not. It resumed what it did previously, writing data to itself (disk5) and then removing the completed file as if it thought it moved it to another disk. Which you can see at the top of the post logs from File Activity plugin. Mover did log a bunch of successful moves of said deleted data. I however am not willing to re-create the scenario on my array again.

I thought about setting the FS to XFS but I didn't want to do anything destructive without checking in here first. Setting fs to xfs allowed the disks to mount prooperly, i will still attempt to wipe the zfs signatures to avoid this. Come to think of it, back when zfs was introduced into unraid, I did format them in zfs to try it in the array as a "hybrid" solution before reverting back to xfs. I wonder if this has something to do with how unraid changed the way it looks for a partition. Either way it's much appreciated. (check your paypal)

root@PlexRAID:~# wipefs /dev/sdd1 DEVICE OFFSET TYPE UUID LABEL sdd1 0x0 xfs 0da6224a-a8f2-468a-a965-29926b90b524 sdd1 0xae9fff44000 zfs_member 16481084777083266639 disk2 sdd1 0xae9fff84000 zfs_member 16481084777083266639 disk2 root@PlexRAID:~# wipefs /dev/sde1 DEVICE OFFSET TYPE UUID LABEL sde1 0x0 xfs 3dd155dd-ea99-43f5-8d0b-7883b96afaae sde1 0xae9fff44000 zfs_member 8582965978458800897 disk1 sde1 0xae9fff84000 zfs_member 8582965978458800897 disk1 Here's some more info if helpful. root@PlexRAID:~# wipefs /dev/sdd* DEVICE OFFSET TYPE UUID LABEL sdd 0x200 gpt sdd 0xae9fffffe00 gpt sdd 0x1fe PMBR sdd1 0x0 xfs 0da6224a-a8f2-468a-a965-29926b90b524 sdd1 0xae9fff44000 zfs_member 16481084777083266639 disk2 sdd1 0xae9fff84000 zfs_member 16481084777083266639 disk2 root@PlexRAID:~# wipefs /dev/sde* DEVICE OFFSET TYPE UUID LABEL sde 0x200 gpt sde 0xae9fffffe00 gpt sde 0x1fe PMBR sde1 0x0 xfs 3dd155dd-ea99-43f5-8d0b-7883b96afaae sde1 0xae9fff44000 zfs_member 8582965978458800897 disk1 sde1 0xae9fff84000 zfs_member 8582965978458800897 disk1 Edit: I also cannot mount them with unassigned devices. The mount button stays greyed out.

Nope, do not have mover tuning plugin installed.

Something went really wrong tonight after I ran new config, and two of my xfs disks are now showing unsupported or no filesystem. All disks were showing auto filesystem, I started the array and only two of my disks came back as xfs mounted, of course a parity sync started which means my parity data is no longer valid... I did not format or do anything with else with these disks. I was trying to simply take one of my empty disks (former disk5), and slot it in for parity2. root@Tower:~# blkid /dev/sdb1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="12F3-2F19" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f7850c60-01" /dev/sdc1: LABEL="zfs" UUID="2102369910678992796" UUID_SUB="10755710579023684102" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/loop1: BLOCK_SIZE="131072" TYPE="squashfs" /dev/sdm1: LABEL="cache" UUID="1551826738277468454" UUID_SUB="7613256705955010305" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/sdk1: LABEL="cache" UUID="1551826738277468454" UUID_SUB="1717029409727760252" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/md4p1: UUID="a6a5c82d-35fb-4d4b-ad33-77d63b7ef916" BLOCK_SIZE="512" TYPE="xfs" /dev/loop0: BLOCK_SIZE="131072" TYPE="squashfs" /dev/sdn3: BLOCK_SIZE="512" UUID="4CC07D0EC07D000E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="71143671-a7a5-4c75-82bf-e392dc7fa9f6" /dev/sdn1: LABEL_FATBOOT="NTFS" LABEL="NTFS" UUID="C878-46AD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="2ae20b36-b82e-4338-9332-03c53a9f7664" /dev/sdn4: BLOCK_SIZE="512" UUID="AC3A06833A064AB2" TYPE="ntfs" PARTUUID="d3845781-9f8d-4620-82ad-71e81f0a8c1c" /dev/sdn2: PARTLABEL="Microsoft reserved partition" PARTUUID="6f35769b-0dfe-4bd2-8991-c1e73f6088e2" /dev/sdl1: LABEL="cache" UUID="1551826738277468454" UUID_SUB="15743817999972033493" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/sdj1: LABEL="cache" UUID="1551826738277468454" UUID_SUB="16464870163669679467" BLOCK_SIZE="4096" TYPE="zfs_member" /dev/md3p1: UUID="1add063d-71eb-4b1a-8336-4b5543a146f9" BLOCK_SIZE="512" TYPE="xfs" root@PlexRAID:~# xfs_repair -nv /dev/sdd1 Phase 1 - find and verify superblock... - block cache size set to 1445120 entries Phase 2 - using internal log - zero log... zero_log: head block 2361908 tail block 2361908 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 8 - agno = 1 - agno = 3 - agno = 6 - agno = 4 - agno = 5 - agno = 7 - agno = 10 - agno = 9 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. root@PlexRAID:~# xfs_repair -nv /dev/sde1 Phase 1 - find and verify superblock... - block cache size set to 1445120 entries Phase 2 - using internal log - zero log... zero_log: head block 567083 tail block 567083 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 3 - agno = 8 - agno = 5 - agno = 6 - agno = 0 - agno = 4 - agno = 9 - agno = 10 - agno = 2 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Both of these appear to return 0 when using "echo $?" plexraid-diagnostics-20250508-0000.zip

Share setting for data is set to high water, however disk5 did have the most free space. i just wouldn’t think this would try to move existing data to the same disk. I even excluded disk5 from all shares and re-ran it to see if that would work, same result.

May 07 15:57:58 MOVED_FROM => /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin.partial May 07 15:57:58 MOVED_TO => /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin May 07 15:57:58 ATTRIB => /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin May 07 15:57:58 OPEN => /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin May 07 15:57:58 DELETE => /mnt/disk5/data/t----s/r----s/B----OG/s-----31.bin Mover seems to be moving the data from disk5 to disk5 and then deleting it when running: mover start -e disk5 |& logger & Am I using it incorrectly? plexraid-diagnostics-20250508-0000.zip

Disable any tonemapping settings, and try again. I found this to be an issue. It works if I turn off tonemapping

I haven't kept up with plex but I don't think plex itself supports B-series intel GPUs yet.

What if you pass through only one specific gpu instead of just /dev/dri?

Curious, if you open the docker console and type in ls -n /dev/dri do you see card0 and renderD128 ? Have you tried the beta version of emby?

for immich to talk to postgres, you have to tell immich to talk to it via it's hostname which has to be spelled exactly as the container name for postgres. for example if postgres container is called "postgresql_immich" you have to refer to it exactly the same way. to test the connection, open the container console and ping the hostname if the container supports ping

Just to recap the events and issues: 1. The first run admin credentials issue was fixed, this allows the user to login with the supplied credentials. Previously this was not possible. 2. The memcached docker requirements IS still an issue. If memcached is not installed or part of the seafile-net custom docker network you will get "Page Unavailable" errors if you do any action in which may throw an error. For example, log in with the wrong credentials. To fix the #2 issue the user either needs to remove the CACHES{} backend from the seahub_settings.py config file OR install memcached and include it in the seafile-net docker network.

The biggest thing to look at is the AMPs on the 12V rail of the PSU sticker regarding HDD counts. Figure out the startup amps of the HDDs and assume they will all start up at the same time (they will at array start) Here's an example, 45.5A is max amperage for disk startup on ALL disks, so if each disk needed 5A to start up for example, this PSU would only be able to handle 8-9 disks max starting up at the same time. Some PSUs have split 12V rails meaning if you have too many disks on a single 12V rail, no bueno.

Toggle the tailscale button on the plex docker container page, set it to SERVE mode, open console, click the link to authenticate, it now should show up on your tailscale admin dashboard, then click the share button next to it like below, and you're done.

Now that the admin login is fixed im going to test out a fresh install to see if the memcached thing is still an issue. Ive removed as well to test. Test complete: it appears it was just the admin email/password issue, not memcached. Edit 2: However, if memcached is not configured, instead of getting the "Invalid Login" page, the user is instead presented with the "Page Unavailable" screen. This would explain the behavior I expereinced because I could not login due the admin/password bug. The two options to remedy this are to either install memcached and add it to the seafile-net docker network OR to remove the CACHES {} portion from the seahub_settings.py (setting it to localhost does not fix it)