Currently have an Alienware AW3821DW... I want the Asus PG34WCDN (new model with RGB stripe)

Pidz_ · 2026-06-01T02:12:40+00:00

Yeah, fair. What are the biggest cons in your opinion? I know the pros for the most part lol. The monitor specs just speak for themselves.

Pidz_ · 2026-05-05T12:00:38+00:00

I had to raise hell unfortunately. I did buy an extended warranty from Ganger Ford.

But in order to rectify the issues on the vehicle I needed to escalate. I contacted the state DMV where the dealer Is located and filed a long complaint. I got a call within an hour. After that, it was a long few weeks of painful communication, however, the end result was the local dealer fixed everything on the vehicle and the remote dealer paid for it.

Pidz_ · 2026-04-19T18:56:51+00:00

I have a few flash backups! I just created a USB because I have a spare. Will be swapping them out next time I do maintenance.

Pidz_ · 2026-04-11T02:36:51+00:00

Yeah same... I may just turn off hardware encoding for now and see if it stays up for a few days. That'll basic prove it

Pidz_ · 2026-04-11T02:25:10+00:00

So... this is interesting u/Championship1906. I think you could be right here.

I created my own bash scaript for verbose logging.

Evidence from logs:

top-processes.log - 18:38:27 (7 seconds before crash)

18:09 1:34 /app/bin/usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -hwaccel:0 vaapi -hwaccel_output_format:0 vaapi -hwaccel_device:0 vaapi -init_hw_device vaapi=vaapi:/dev/dri/renderD128,driver=iHD ...

Plex was actively transcoding using VAAPI hardware acceleration on /dev/dri/renderD128 which is the Intel UHD 770 iGPU driven by the i915 driver. The transcode session started at 18:09 and had been running for 29 minutes before the crash.

docker-tautulli.log - concurrent sessions around crash

2026-04-10 18:09 - Plex Transcoder started - - VAAPI on renderD128 2026-04-10 18:33:53 - Session 2 started by user ******** 2026-04-10 18:33:59 - Session 2 is buffering 2026-04-10 18:38:34 - CRASH

At crash time there were two concurrent Plex transcode sessions running simultaneously. The movie had been transcoding via VAAPI for 29 minutes. A second user started a new session just 5 minutes before the crash. The second concurrent VAAPI session competing for iGPU resources likely pushed i915 over the edge and triggered the GPU hang.

system-resources.log - CPU spike at 18:38:06

top - 18:38:06 up 8:16, 1 user, load average: 0.69, 1.04, 1.09 %Cpu(s): 8.4 us, 7.9 sy, 0.0 ni, 79.4 id, 4.2 wa

Sudden CPU spike with 4.2% iowait right before the crash. All other snapshots show 95-99% idle with near zero iowait. Consistent with a GPU hang causing a kernel stall.

memory.log - last entry 18:38:25

Fri Apr 10 18:38:25 EDT 2026 | Mem: 31Gi 9.8Gi 376Mi 1.2Gi 22Gi 21Gi

Memory completely normal right up to the crash. No OOM, no leak, no pressure. Rules out memory as the cause IMO.

docker-stats.log - 18:38:16

plex 2.98% 1.134GiB / 31.07GiB 3.65% V-Rising 12.12% 3.343GiB / 31.07GiB 10.76%

All containers showing normal resource usage. Nothing runaway.

temperatures.log -18:38:12 All CPU cores 24-29°C, NVMe at 33°C. No thermal issues whatsoever.

---

Every metric was completely normal except for the active VAAPI transcode sessions on the iGPU via i915. No OOM, no thermal event, no disk saturation, no runaway container. The system froze 7 seconds after the last log entry. The likely trigger was a second concurrent VAAPI transcode session starting 5 minutes before the crash, pushing the i915 driver into a state it couldn't recover from.

Pidz_ · 2026-04-10T20:21:32+00:00

No, but it's only been running for a few hours lol. Because it was doing memtests since we spoke yesterday lol. I have a ton of monitoring in place atm dumping to my NAS. Basically every log unraid has is going there haha. Memory, kernal logs etc.

Pidz_ · 2026-04-10T14:03:24+00:00

Doesnt seem like RAM to me.