MowMdown

I can confirm the GPU reports incorrectly the link speed. My A310 always shows x1 as well regardless of what it's doing.

have you checked the BIOS to see if the drives are detected? I would double check the cables.

No reason to move to the Xe driver for media encoding/decoding at this time that I am aware of. A series cards are supported on both drivers, future GPUs from intel may only operate on the Xe driver. There seems to be a fundamental misunderstanding of how hardware works in conjunction with how video transcoding operates. GPU usage should hit 100% and hitting 100% does not mean that the GPU cant do more than one single task. The GPU will easily burn though media re-encoding to fill the transcoder buffer and stop until the buffer needs to be replenished. This can run concurrently with many streams as they will need buffers at different times. Also the number of media engines on a GPU plays a role. You would need to refer to LSIO documentation on how to use their container variables.

Your iGPU is not detected, probably disabled when a dGPU was installed, is my guess. You will need to poke around in the BIOS to see if you can re-enable it. As for the P400, your probably not using the legacy nvidia drivers which is required.

Type in lspci | grep VGA into the unraid console/terminal and post the output result.

Not relevant in this case. A380's are well supported in the linux kernel. The new B-Pro series are not.

Your buffering issues are likely network related not plex/GPU related. The Roku is direct playing which means the GPU is not involved at all. Entirely disk read speed and network driven Also you have a intel i5-14500 which has an iGPU built in, not sure why you added an Arc GPU when they do the same thing. This is beside the point. You should also increase the throttle buffer from 60 seconds to at least 120 seconds or more, I prefer 300 seconds For reference Ive been using an A310 arc gpu w/ 4k content.

traefik writes logs to /mnt/user/appdata/traefik/logs/ not the host's own /var/log/... You're looking in the wrong spot.

Please post diagnostics

Do any logs actually appear in /mnt/user/appdata/traefik/logs when traefik is running? Ff you dont see logs in this folder on the host, crowdsec wont see any either if you cant. What you are doing looks correct at a first glance. Paths look like I would expect.

Probably something windows is doing that is skipping the smaller partition for whatever reason windows has. Why not just format it on unraid?

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/ You will want to follow these procedures. Videos can be out of date the docs should always be current.

To be honest, I would not have been running correcting parity checks until after a disk rebuild. Unraid doesn't know if the parity data is valid or the array data is valid and you've been force updating the parity data based on the array data which may or may not have been problematic. For all we know now is that the data on the bad disk is malformed and potentially could have been saved when rebuilding for parity assuming parity was still valid. Im not an expert on parity rebuilds or sync errors so take what I say with a grain of salt but this is what my first thought is. I see no value in running a parity check at this point. I would say, re-evaluate the data once the rebuild is finished. If it looks good no further may be action required.

Just keep in mind, split level is the highest priority/takes precedence above fill allocation and minimum free space. I personally just use rsync to move files, not sure if there is a "better" way.

Say you have a level 2 split, /mnt/user/share(l1)/subfolder(l2)/lastfolder(l3)/files.txt If you write subfolder(l2) to Disk1, all future folders and files that would be wrote to subfolder(l2) will forever and always be wrote to disk1 regardless of free space or the allocation method. That's why the manual split was never writing to any other disk.

Please post diagnostics with the USB drive attached. Also can you provide a screenshot of the webgui page where you expect to see the USB HDD. Thanks (helps when we see what you see) I would also suggest installing the Unassigned Devices Plus plugin as well as it may be necessary.

Honestly, you probably just want to use the "automatically split any directory" split level unless you have a reason to restrict how data is split. If you restrict it too much like youve done already, you'll never write data to a second disk because unraid wont split due to folders that data is wrote to existing on the disk already.

If the water damaged disks are able to power up you might be able to use UFS Explorer to see/recover data if possible. The free trial should let you at least see what's potentially on the disks. However without having both parity disks, you have too many failed data disks for parity to function at this point.

Enable the remote syslog server to capture system logs between reboots. 2. Are you transcoding plex to RAM? If that's the case, you probably shouldnt do that without increasing your RAM Running low on RAM can cause webgui unresponsiveness.

Since this post seems to be getting some attraction: Here is the full "stock unraid" limine.conf with all applicable unraid stock boot options. In case anyone wants the full suite of options to boot from. menu_title: Lime Technology, Inc. default_entry: 1 timeout: 5 /Unraid OS protocol: linux kernel_path: boot():/bzimage module_path: boot():/bzroot comment: Unraid OS /Unraid OS GUI Mode protocol: linux kernel_path: boot():/bzimage module_path: boot():/bzroot module_path: boot():/bzroot-gui comment: Unraid OS GUI Mode /Unraid OS Safe Mode (no plugins, no GUI) protocol: linux kernel_path: boot():/bzimage module_path: boot():/bzroot cmdline: unraidsafemode comment: Unraid OS Safe Mode (no plugins, no GUI) /Unraid OS GUI Safe Mode (no plugins) protocol: linux kernel_path: boot():/bzimage module_path: boot():/bzroot module_path: boot():/bzroot-gui cmdline: unraidsafemode comment: Unraid OS GUI Safe Mode (no plugins) /Memtest86+ protocol: linux path: boot():/memtest comment: Memtest86+

You would create scripts using the user-scripts plugin and execute them at "First Array Start"

Unless you are manually running parity checks, that setting doesn't affect scheduled parity checks. As to why it's not persistent, couldn't' tell you.

Ok so Disk1 just finished, after emptying it and before I ran a format it was showing a FS overhead of 136GB which seems quite low for a 12TB disk. After doing a format, it's now reporting 230GB FS overhead. That only accounts for about 94GB of the ~156GB difference. After Rsync was finished After Disk1 was emptied Disk1 formatted

Post diagnostics please

I have an odd question, related to migrating data between two XFS disks. Both were/are on V5. Background. I have been converting my XFS disks from unencrypted to xfs-encrypted. Here's where it gets weird all my disks are either Seagate IronWolf 12TB (non-pro) or WD Red Plus 12TB drives. I threw in an empty disk, formatted it as xfs-encrypted and ran rsync -aHAXx --numeric-ids /mnt/diskX /mnt/diskY then rinse and repeat up the drive order, fomat the now emtpy disk as xfs-encrupted, and re-run the rsync command for the next two disks Disk4 -> DIsk5, Disk3 -> Disk4, etc.. However when I got to disk2 which was 96% full, after the rsync to disk3, disk3 is now reporting 97% full with fewer remining free space than what disk2 previous was showing. Both disks contained identical copies as I didnt delete the source data. Disk2 was showing 411GB Free where as DIsk3 was now showing 257GB free. Does this make sense? Does LUKS add several GBs of extra overhead on top of the overhead XFS already adds? I knew in my case XFS adds about 230GB of used space for the filesystem metadata/reflinks etc... but how do I "lose" an extra 150GB on top of that? Here is the image when it was nearly finished and I was already showing less free space than disk2 (you can see it is transferring 11,511,081,008,711 bytes) Im currently in the process of moving disk1 now to disk2, here is the before You can see disk2 has nothing on it before I started so I know 230GB is how much the FS takes up. The question I have is does the 512 sector vs 4096 sector change how data is stored and reported? ~# xfs_info md2p1 meta-data=/dev/mapper/md2p1 isize=512 agcount=11, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=0 data = bsize=4096 blocks=2929717235, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0 ~# xfs_info /dev/md1p1 meta-data=/dev/md1p1 isize=512 agcount=11, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 nrext64=0 = exchange=0 metadir=0 data = bsize=4096 blocks=2929721331, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0