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.

Hi guys, have there been any breaking changes in Tdarr recently? I'm running the :qsv branch and I just noticed that all my automatic transcodes of h264->hevc have been failing for at least 2 weeks now (don't ask busy at work, so no time to check my logs before), while everything had been working for several months without problems. At first, I thought it might have to do with bad input files, but running them through my separate Handbrake watch folder worked fine (also using the QSV /dev/dri device as I'm using in Tdarr). Using the same files in Tdarr produced errors, I kept getting "ERROR: avio_open2 failed, errno -2" error messages in the transcoding log. I switched to a non_qsv h265 profile that is otherwise identical, and with that transcoding works, albeit painfully slow. tl;dr: QSV is effectively broken for me and I'm looking for a fix. Any ideas? EDIT: Problem was caused by a misconfiguration on my system, preventing Tdarr from accessing the tdarr-cache path on the SSD.

Hey guys, how can I use Tdarr to transcode my library of audio files down from way too high quality rips? I have a ton of flac and mp3-320 files that I would like to cut down in size by converting them to mp3-192 (more than good enough for my ears and equipment). I guess I'm supposed to use something ffmpeg related, but I'm at a loss how to handle non-video files using which plugins... Any help greatly appreciated!

I wonder if it would be possible to have this plugin split the backup archive into smaller chunks, to make for easier offsite secondary backups. Right now my tar file is about 140 GB in size, and getting that synced offsite is proving problematic for me. It would be much easier if there was an option to create nice handy chunks of 2 to 4 GB. Any ideas?

Thanks to lots of help from @darkreeper, I've been making good progress in getting Tdarr set up to handle my huge library of recordings. There are some things I could not resolve so far: - I'm already using the :qsv branch of the image, so Intel QSV works for Handbrake, but somehow not for ffmpeg. Apparently, ffmpeg hasn't been built with support for h264_qsv enabled - When transcoding .ts using ffmpeg, it appears that streams containing Teletext are also dropped, probably due to libzvbi-teletext not being built into the image Is there any way to fix this for me? EDIT: Managed to fix the second point by using ",-map 0:v? -map 0:a? -map 0:s? -map 0:d? -map 0:t? -c copy -c:v libx264" as ffmpeg parameters to explicitly include all those streams... funny that a "-map 0 -c copy" didn't do the job here... But hey, at least it works now...

As far as I know, H264 is the maximum supported by my boxes for .ts files. I can always transcode them to something more advanced later on.

Yes, of course, just let me know where I can put the file. Thank you.

Enigma2 is basically the software foundation running on popular Linux receivers like the Dreambox or Vu. Put simply, it takes whatever comes down through DVB-C/S/T and stores it in a .ts container. For my old recordings, this mostly looks like this: Newer recordings benefit from the fact that TV stations (like ZDF) have adopted H.264 for the video stream, saving lots of bandwidth and in my case, storage on unRAID: So in addition to converting from MPEG2 to H264, it might also be necessary to move the Teletext stream down a bit, since I understand that Tdarr needs the video stream to be the first in the file for proper codec recognition. As for Enigma2 requirements, I don't think there really are that many other than the .ts conforming to the standard used by DVB. I can provide a sample file via Dropbox or something, if the description is not sufficient. Thank you.

Oh man, this works great! Thanks for this software! I managed to get a good chunk of my video library monitored to ensure h265/mkv for any new stuff. Maybe one of the experts here could help me figure out how to deal with old enigma2 recordings properly. They are in .ts containers and the old ones are in mpeg2 format, while I would like them to be converted to h.264 for better space efficiency, while retaining good compatibility with my existing enigma2 players. As far as I understand, this should somehow be manageable using ffmpeg, but I'm not sure about how to get this going in Tdarr without ruining my library.

Does this image contain the Handbrake CLI? I seem unable to find anything about it in the documentation...

How would I go about adding Handbrake in this container, so I can use HandbrakeCLI to automatically transcode my DVR recordings to H.265 using Plex's "postprocessing script" feature? Any ideas?