Jclendineng

just found out about this, competitors need to hammer on this as a downside of a container system that takes months to fix what seems to be a pretty major issue.

Any updates? Ive tried a few things to get QSV working in handbrake (linuxserver docker) but it's not working. Latest unraid. I hear Unraid 7.3 is coming shortly with kernel 6.18 (about time...) which may help Intel compatibility. Edit after banging my head on this handbrake issue for a bit: Set up handbrake per linuxserver doc and start. Go to the console and install the proper packages, by default this for some reason does not have qsv enabled. Install: pacman -S vpl-gpu-rt libvpl --overwrite "/usr/lib/libgcc_s.so*" --overwrite "/usr/lib/libstdc++" --overwrite "/usr/share/licenses/gcc-libs/" Restart the handbrake container and profit.

Just so I’m clear, this isn’t intended for GPU stats, mostly iGpu. My a380 worked fine with it but my b50 pro stats aren’t showing up so I should be good to uninstall this?

I’m wondering how this calculates sizes, free space, raw and used don’t make any sense. The numbers are wildly off from actually used free and raw. Anyone else notice this? I’m about to stop using the plugin but unraid doesn’t natively give you that info does it?

I am on 7.2 but this has been happening the past few releases. All the hang logs when ps -ef 'ed show the one I append a message to below. It doesn't seem to do anything except spam my logs with these messages but figured Id see if anyone else has seen this. I have an Arc A380 LFF GPU that I use for Immich encoding, scrypted decoding and object detection, Plex encoding and that's essentially it. Aug 22 13:18:01 Unraid kernel: i915 0000:03:00.0: [drm] python3[354709] context reset due to GPU hang Aug 22 13:18:01 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [354709] Aug 22 13:17:17 Unraid kernel: i915 0000:03:00.0: [drm] python3[352587] context reset due to GPU hang Aug 22 13:17:17 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [352587] Aug 22 13:15:21 Unraid kernel: i915 0000:03:00.0: [drm] python3[349936] context reset due to GPU hang Aug 22 13:15:21 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [349936] Aug 22 13:10:36 Unraid kernel: i915 0000:03:00.0: [drm] python3[338640] context reset due to GPU hang Aug 22 13:10:36 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [338640] Aug 22 13:06:35 Unraid kernel: i915 0000:03:00.0: [drm] python3[335984] context reset due to GPU hang Aug 22 13:06:35 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [335984] Aug 22 13:00:50 Unraid kernel: i915 0000:03:00.0: [drm] python3[98984] context reset due to GPU hang Aug 22 13:00:50 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [98984] Here is a list of running Python processes: oot 374893 374856 0 Sep08 ? 00:01:14 /usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisord.conf nobody 1105262 1104575 0 07:55 ? 00:00:00 python3 -m immich_ml nobody 1105306 1105262 0 07:55 ? 00:00:02 python -m gunicorn immich_ml.main:app -k immich_ml.config.CustomUvicornWorker -c /app/immich/machine-learning/immich_ml/gunicorn_conf.py -b 0.0.0.0:3003 -w 1 -t 120 --log-config-json /app/immich/machine-learning/immich_ml/log_conf.json --keep-alive 2 --graceful-timeout 10 nobody 1105315 1105306 0 07:55 ? 00:00:31 python -m gunicorn immich_ml.main:app -k immich_ml.config.CustomUvicornWorker -c /app/immich/machine-learning/immich_ml/gunicorn_conf.py -b 0.0.0.0:3003 -w 1 -t 120 --log-config-json /app/immich/machine-learning/immich_ml/log_conf.json --keep-alive 2 --graceful-timeout 10 root 1521684 1520200 0 Sep15 ? 00:02:48 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1559896 1558292 0 Sep15 ? 00:02:45 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1561447 1560160 0 Sep15 ? 00:02:44 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1563652 1562319 0 Sep15 ? 00:02:44 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1707389 45605 0 15:35 ? 00:00:12 /usr/bin/python3.9 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/tensorflow-lite root 1707512 45605 0 15:35 ? 00:00:24 /usr/bin/python3 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/ncnn root 1712923 45605 9 15:39 ? 00:20:07 /usr/bin/python3 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/openvino root 1712964 1712923 0 15:39 ? 00:00:00 /usr/bin/python3 -c from multiprocessing.resource_tracker import main;main(11) - THIS IS THE PROCESS LAST LISTED IN THE LOG unraid-diagnostics-20250917-1919.zip

FYI Just on a whim I downloaded Windows 11 Dev Build 26120 using UUPDump and created an autounattend.xml for it and it works, so the issue appears to have been Microsoft being Microsoft and breaking stuff in stable again, so kinda like every patch Tuesday.

FYI Windows 11 VM creation still 100% broken by default in latest version.

Unfortunately this makes the VM dog slow. Looking for a better solution, but it takes 10x longer to install than previous versions.

FYI I took what you posted and ran some tests, I don't about pass thru but for the UNSUPPORTED PROCESSOR BSOD on initial install, you only need to add 1 feature under topoext: <feature policy='require' name='topoext'/> <feature policy='disable' name='arch-capabilities'/>

Dang I have been dealing with this for AGES. Thanks! I'll need to bake the hypervisor settings into my AutoInstall windows 11 ISO. Edit: If you use an autounattend.xml you need to add this to the system context, before first login: $ConfirmPreference = 'None' Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart $ConfirmPreference = 'High' It should do an automatic restart anyways for the other autounattend.

Small request, would it be possible for the pool size to match the actual "useable" size vs the entire size + zfs overhead? If I have a 200TB pool, zfs master reports around 200TB vs the 120 or so with the parity + overhead. I don't know if this is possible but it would make it really handy for setting quotas, so we can see exactly how much we have without pulling out a calculator every time. :) The dataset size seems decently accurate, so I usually just add up all used space from each dataset then subtract that from the useable space from zfs pool info then calculate out how big to make my quotas.

Ok, crashed again. I’m starting by removing my intel arc GPU and will try and crash it again, then I’ll remove a ram stick. Edit. Crashed without the Arc card, I then removed a ram stick and crash, replaced the other one and still crashed. I’m disabling PBO and all core boost in BIOS to see if the CPU is going bad. Edit. After disabling all CPU boosts in BIOS I transferred about 1TB of data from multiple sources to the disks, along side running a couple VMs. No crash as of this morning, I’ll hammer it today and try and get it to lock up, if that “fixes” it, it means I have a bad 7950x which isn’t unheard of.

I’ll try that next time it hangs. I moved 500gb between drives to try and trigger it, and started a drive replacement to see what the process was and no lockups in about a day. It’s so strange it happened maybe 10 times yesterday. I replaced my PSU with a higher wattage one in case that was the culprit, no dice. I just can’t get it to be consistent. Checked slack logs as well and everything is hunky dory, just will randomly lock up and require a hard reset.