-
Server nearly unresponsive when transcoding with iGPU
Will do, thank you both!
-
Server nearly unresponsive when transcoding with iGPU
Sorry for the delay. I caught it happening again. Hopefully this helps! Plex Media Server Logs_2025-08-10_20-03-43.zip
-
Server nearly unresponsive when transcoding with iGPU
Linuxserver.io version: 1.41.9.9961-46083195d-ls274 Build-date: 2025-07-21T09:36:12+00:00 ─────────────────────────────────────── Setting permissions on /tmp **** Server already claimed **** **** permissions for /dev/dri/renderD128 are good **** **** permissions for /dev/dri/card0 are good **** Docker is used for versioning skip update check [custom-init] No custom files found, skipping... Starting Plex Media Server. . . (you can ignore the libusb_init error) [ls.io-init] done. Critical: libusb_init failed I had a Nvidia GPU installed as well, i just removed it. Not sure if that could have contributed to the issue.
-
Server nearly unresponsive when transcoding with iGPU
docker run -d --name='plex' --net='host' --pids-limit 2048 -e TZ="America/Denver" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="plex" -e 'VERSION'='docker' -e 'PLEX_CLAIM'='claim-' -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='https://[IP]:[PORT:32400]/web' -l net.unraid.docker.icon='' -v '/mnt/user/plexmedia/tv':'/tv':'rw' -v '/mnt/user/plexmedia/movies':'/movies':'rw' -v '/mnt/cache/appdata/plex':'/config':'rw' --device=/dev/dri 'lscr.io/linuxserver/plex' c8a146798f09b03aec0435b937953cf248f62c8bd1d777d48e60fd5c31495b0e Plex does show iGPU in settings. it is currently selected.
-
Server nearly unresponsive when transcoding with iGPU
When it's transcoding, it is nearly unresponsive and almost all CPU cores are at 100%. This comes and goes but is fairly consistent when transcoding. GPU TOP does show plex utilizing iGPU. I'm using an i5-14600K. When it happens, only one user is transcoding. iGPU shows maybe 1% - 5% load while CPU is basically pinned. I also see high interrupts/Sec sometimes spiking to 50,000+. Thanks for any and all help. tower-syslog-20250724-0048.zip
-
Containers Will Not Update
It's all my containers, not just immich. And I've tried probably 50 times at this point. None of them will update.
-
Containers Will Not Update
tower-diagnostics-20250428-1024.zip
-
Containers Will Not Update
I just tried that with Immich and it did not work. Went through the whole process but still shows update available.
-
-
Containers Will Not Update
Containers show they have an update. I apply the update, it goes through the whole process successfully. However, when i go back to the docker page it still shows "update available". I have created a new docker image 2 times before this because of this same issue. That fixes it for a few weeks but it happens again eventually. This is the third time. Thanks syslog.txt
-
1888 Parity Sync Errors
So the errors it corrected are probably okay then?
-
1888 Parity Sync Errors
This morning I logged in and found that the system was running a correcting parity check and had corrected 1888 sync errors. This was not a scheduled parity check. I performed a clean shut down the other day to remove a few cache drives I had replaced. Turned the system on and didn't notice it started a correcting check. I ran a non correcting check a few weeks ago and found zero errors. My question is how screwed am I if these sync errors were not actual errors. Can I be sure that there is no corruption caused or is it far too late? Is it really this easy to cause corruption if you don't catch the system starting a correcting check? tower-syslog-20250227-1527.zip
-
Constant problems since moving to new CPU/motherboard/chassis
Thanks for the advice. I moved both cache drives to different slots on the backplane after finding no issue with power or cables. The same errors returned. I then moved both drives to the onboard sata controller and got the same issue again. I used brand new cables for power and sata. In SMART report for both drives I see "6254 --- Number of Hardware Resets" Should I replace both cache drives at this point?
-
PapaHVAC changed their profile photo
-
Constant problems since moving to new CPU/motherboard/chassis
Previous system was in a regular case and had an AMD 3700x. Never had a single issue for years. I have moved to an Intel 14600k, ddr5 ecc ram, new motherboard, HL15 case, and added a LSI 9305-16I in IT mode. The motherboard ended up failing a day after i had purchased it and caused a few unclean shut downs, wouldn't boot past BIOS, and eventually just wouldn't even turn on at all. Was sent a new motherboard and it was working normally. New motherboard bios has been updated to most current version. Everything was seemingly working fine. Appdata backup plugin ran at midnight and woke up to dozens of alerts that dockers we unable to start back up. I'm now constantly getting 403 errors on dockers. They just randomly stop working, i restart them, and get the execution error. Now i am noticing a lot of BTRFS errors among others. Any help is appreciated. tower-syslog-20250221-0016.zip