drdebian

Just wanted to let everyone know, that upgrading to 7.1.2 went smoothly and solved this problem (as was to be expected). Intel QSV is now working like a charm again.

Thanks, I wasn't aware of that. I'm actually running 7.0.1, as you can see from the diagnostics attached. ul18s008-diagnostics-20250430-1608.zip

Hi guys, I seem to have lost Intel QSV after upgrading to a new motherboard (Gigabyte B860M DS3H) and CPU (Intel Core Ultra 7 265). There no longer seems to be a /dev/dri even though the i915 module is loaded. intel_gpu_top tells me that "No device filter specified and no discrete/integrated i915 devices found". I can see that the internal graphics are physically there by inspecting the output of lspci. Is there another plugin I need to install to get things going? I'm asking because I had to get the RTL8125 plugin to enable 2.5G networking, maybe there's something similar for the iGPU? I'd be really grateful for any hints on how to track down the issue and get /dev/dri working again.

If you mainly want to transcode video, Intel Quick Sync built into every Intel CPU is definitely the most power efficient way to go.

Seems like there's a parameter you can set in the AAC converter plugin that defines the desired sample rate: -ar 48000 The AAC normalization plugin, however, sports no such parameter and promptly converts the audio tracks previously converted to 48kHz up to 96kHz ones again. The only way to save my library from being converted 96kHz sample rate over and over again was to remove the AAC normalization plugin altogether.

I recently switched to Unmanic for keeping my video library encoded properly and it works great. Turns out, however, my new Samsung TV (or rather the Plex version on it) doesn't seem to like the 96 kHz AAC audio the default settings of the reencoding plugin produce. I'd like to reduce the bitrate to 48 kHz, but I'm not sure about which options to put where in the plugin config. Any help would be greatly appreciated.

Please, don't try to help me all at once... 😂 It's great to have to rm /var/log/* every day to keep the system running.

Ever since I upgraded to the latest version of Unraid, I keep getting alerts from the "Fix Common Problems" plugin regarding my /var/log being almost full. Indeed it is, with the biggest files being syslog*. Looking at the syslog files more closely, 99% of their contents look something like this: Aug 6 03:14:19 ul18s009 nginx: 2023/08/06 03:14:19 [error] 3265#3265: *6574127 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/notify?buffer_length=1 HTTP/1.1", host: "localhost" Aug 6 03:14:19 ul18s009 nginx: 2023/08/06 03:14:19 [error] 3265#3265: MEMSTORE:00: can't create shared message for channel /notify Aug 6 03:14:20 ul18s009 nginx: 2023/08/06 03:14:20 [crit] 3265#3265: ngx_slab_alloc() failed: no memory Aug 6 03:14:20 ul18s009 nginx: 2023/08/06 03:14:20 [error] 3265#3265: shpool alloc failed Aug 6 03:14:20 ul18s009 nginx: 2023/08/06 03:14:20 [error] 3265#3265: nchan: Out of shared memory while allocating message of size 9033. Increase nchan_max_reserved_memory. Aug 6 03:14:20 ul18s009 nginx: 2023/08/06 03:14:20 [error] 3265#3265: *6574133 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/devices?buffer_length=1 HTTP/1.1", host: "localhost" Aug 6 03:14:20 ul18s009 nginx: 2023/08/06 03:14:20 [error] 3265#3265: MEMSTORE:00: can't create shared message for channel /devices Aug 6 03:14:21 ul18s009 nginx: 2023/08/06 03:14:21 [crit] 3265#3265: ngx_slab_alloc() failed: no memory Aug 6 03:14:21 ul18s009 nginx: 2023/08/06 03:14:21 [error] 3265#3265: shpool alloc failed Aug 6 03:14:21 ul18s009 nginx: 2023/08/06 03:14:21 [error] 3265#3265: nchan: Out of shared memory while allocating message of size 9033. Increase nchan_max_reserved_memory. /var/log seems to be mounted like this according to /etc/mtab: tmpfs /var/log tmpfs rw,relatime,size=131072k,mode=755,inode64 0 0 Any ideas how to further track down the issue?

I'd go with the i9-9900k, it's gonna make your build much more future proof. If you're running Plex, you'll definitely want the extra horsepower for hardware transcoding using Intel's QSV, which is cheaper and less power hungry (=cooler) than a dedicated GPU for this use case. You'll also appreciate the faster CPU for the nightly jobs Plex is going to run over your library, scanning for intros, creating thumbnails and whatnot, none of which would benefit from GPU or QSV.

Is that gonna include using something like pigz for multicore compression of backups? Would love to see that! In the meantime, is there any way to make the plugin use pigz instead of gzip for compression of files?

I'd recommend Tdarr instead, watching over target folders only.

I have the same problem, something appears to be broken in the nftables script. As far as I can tell, you're not going through the VPN nor Tor due to those problems.

I wouldn't dare try, it says it may break at any time... not something I want for managing my network...

too bad there's no 6.0.x version of this yet... I have to run the controller on a raspberry pi in the meantime...

Thanks for the quick reply, you got me onto the right track for solving the problem. Turns out that when I first installed Tdarr, I created a share for the Tdarr cache (which was never really used). For some reason, this share now was set to "Use cache drive: yes" (previously no), which in consequence prevented Tdarr from using that path on the SSD directly. Setting the share back to not using the SSD fixed the problem immediately. I will remove the unnecessary share at the earliest opportunity.