aglyons

CA Submission is in! Fingers crossed ;)

Starting this new thread to prepare for submission to the CA. I've been working on this project for the past couple of weeks, and I think I'm at the point where other people can start trying it out! StaXXDocker Compose stacks for Unraid, with a form instead of YAML. StaXX is a plugin for Unraid 7.2+ that manages your containers using standard Docker Compose stacks instead of Unraid's XML templates. Paste in a compose file from anywhere, and it just runs. If you would rather not touch YAML, StaXX reads the file and builds a settings form from it, so you can configure a container the same way you do today. Whatever you save is still a plain compose file that works unmodified anywhere else. I've been building in lots and lots of features with a lot of automation as well that automatically fills things in like file paths and will automatically connect the same values that are used in a multi-service stack or even across stacks! Honestly, I can't keep up with all the things that I've been shoving into this! I'm working on updating all of the documentation as well, but you can try it out and let me know what you think. I think it's pretty intuitive. Key Features Runs standard compose files, unchanged Intelligently turns a compose file into a settings form Imports and converts your existing Unraid template containers Imports a Docker Hub image as a starting stack; just give it the URL Groups stacks into folders on one page (Replaces FolderView) Start, stop, restart, recreate, realtime logs, shell and file manager for each service Checks for image updates on an intelligent learning schedule Roll back to a previous image build or historical YAML version independently Pin an image to one exact build Keeps an edit history of each compose file Autostart with the server and chosen order Export a stack as a shareable bundle* Optionally integrates deeply within the Unraid UI GitHub: https://github.com/quadcom/StaxxFeedback and feature requests: https://staxxfb.quadcom.ca Bug reports and ideas are welcome on the feedback board. Tell me what breaks. I'll be releasing v 00.02.00 in a little while. It's a pretty big one, lots of tweaks and cleanup happening.

I was on the ":latest" tag forever, along with the "latest" env var, so it was always bleeding-edge, not a beta version just the very latest releases. I tried a few different tags before I hit this one, from I believe 8 months ago, that started working properly again. During this time, there were no definitive logs to show what was happening. All that would happen is the GPU would just stop handling the transcode, and it would silently flip to the CPU. I wouldn't even notice anything different about the stream. But the CPU would jump to 100% for a single stream. I should add that it also ONLY ever happened when tonemapping was involved. A straight 4k SDR to 1080p wouldn't crash at all.

***UPDATE: Downgrading Plex to tag 'plex:1.43.1.10576-06378bdcd-ls300' has resolved the tonemapping via OpenCL so all is back to working again on i915 with the A380. Tested with 5 4K HDR tonemapped 1080p streams. Flawless with headroom. They've broken the pipeline somewhere since then Careful you don't get bit by the built-in update catch! If you have an ENV var set to "latest", Plex will update itself inside the container, so it won't matter what image you point at. Set the env var to "docker"; that will lock the Plex version in the container to the version specified by the image tag. I'm running the Linuxserver image, so the full image is lscr.io/linuxserver/plex:1.43.1.10576-06378bdcd-ls300

Is this not the support forum for the Intel GPU TOP plugin? The plugin support link sent me here. Fairly recently I've been having problems with my A380 with Plex where HW transcoding starts but after a few minutes it falls back to CPU. I've tried everything so far that I can find, blocking the i915 and forcing XE. But XE doesn't support tonemapping so it's back to i915. I've now started down grading Plex releases but havn't found one that's stable in this regard. I have posted a thread in the general support but I thought I would come here for more specifics. ***UPDATE: Downgrading Plex to tag 'plex:1.43.1.10576-06378bdcd-ls300' has resolved the tonemapping via OpenCL so all is back to working again on i915 with the A380. Tested with 5 4K HDR tonemapped 1080p streams. Flawless with headroom. I'm running the Linuxserver image, so the full image is lscr.io/linuxserver/plex:1.43.1.10576-06378bdcd-ls300

I figured I'd ask here first in case anyone else has run into this problem and found a solution. Let's compare notes; I'm running a smaller AMD 8500G on an Asus B650M board. A380 is in slot two, limited to 1 PCIe lane, unfortunately. The disk controller is in slot one for the lanes.

Very recently I've started to notice that any 4k HDR source that transcodes (and tonemaps because, yes it needs to) will randomly crash the encoder and fallback to CPU. This came up trying to troubleshoot another issue in that I have an AMD iGPU that was caught in the dri mapping snafu. You thought you were using the Intel when in fact you were running the AMD. Result=glitches, corruption just unwatchable. I've been going down a rabbit hole trying to get HDR tonemapping while transcoding workg again and every approach I go down has been a failure. I now come to the understanding the using the XE driver can't do tonemapping at all. It can transcode down in scale but can't tonemap. If that's on, it straight to the CPU without even trying. What does Unraid need to have in order to get this working?! And I am floored that I don't see anyone else talking about this, unless I'm the only one that has something borked!

Was the reason for moving to the XE due to performance? I just pulled my older Nvidia card and put in an A380, and my first test was a major disappointment. One 4KHDR>1080 stream, and the GPU was hitting 94% usage. No better than the Nvidia card I had just pulled. Does the XE driver fix this? Also, is the ":plexpass" tag for lscr.io images?

My intention was not specifically JUST Unraid, but also the containers and VM's running on the system. I ran into an issue with Penpot using compose, where the exporter container was crashing and restarting so quickly that the UR UI couldn't report the restart loop. Only looking at the log files informed me of what it was doing. If this internal AI had been watching the logs, it could have informed me much earlier. As it stands right now, unless you are watching logs on a regular basis, which I suspect the majority of UR users are not, there could be issues happening in the background, causing other issues that are hard to trace for the average user.

I came across an AI log file scanner that would diagnose issues and humanize responses by explaining what is going wrong. It also provided steps to resolve the problem. I commented on the GitHub project, suggesting that a local AI agent could monitor Unraid/Docker/VM logs in real time and alert the sysop to any issues it finds, along with relevant solutions. Think "Fix Common Problems" on steroids. I did not receive a response from the maintainer. GitHubGitHub - YEDASAVG/Stratum: AI-powered Log Intelligence Sy...AI-powered Log Intelligence System - Semantic search, anomaly detection, and root cause analysis for logs using RAG techniques. Built with Rust, Axum, NATS, ClickHouse, and Qdrant. - YEDASAVG/Stratum

Currently, on the Docker page, whenever a container starts, stops, updates, etc., the entire page refreshes to display the container's current state. Using the compose plugin, containers are orphaned when the stack is updated. Clearing out orphaned containers can only be done one by one and requires a full page refresh for each. This takes more time and places more demand on system resources. An ASYNC refresh of changed content would dramatically speed up the process and enhance user experience. Any area of the UI could employ the same ASYNC refresh backend, further enhancing the user experience and system responsiveness.

I suggest allowing only approved individuals access to download the diagnostic files that community members upload. I understand that the data is sanitized and redacted. However, whenever I upload a diagnostic file, my UniFi IPS goes off the charts with blocking requests to my server. I get that this is a community and everyone is here to help each other out. But there is no way to be entirely sure that everyone here is being honourable and decent. I can only speak as to my experience and what I see happening. Perhaps only allow those with a certain number of verified answers to other posts? Forum admins? Forum moderators? Could there be further obfuscation of the data contained in the diagnostic files, such as any domain names or internal/external IP addresses? My network was relatively quiet regarding penetration attempts, but I recently posted a thread and attached my diagnostic file. Ever since then, I have been logging over 100 attempts a day to various ports and to my NPM container. And I'm a home user, not a big corporation. Thank god I went with the Unifi gateway to help block all this. Not cool. A.

I'll run the iperf. Just so I am clear, if an array folder has a cache-first config, when writing to the array, the files will initially be copied onto the cache pool, and then the mover 'moves' the files to the array. If this is not the 'understood' function, do I have to specifically state the files are landing on a cache pool, regardless of the fact that the mover will relocate the files? I chose to be specific about the config in the event that a pool array behaves differently than a shared folder cache config. Yes, they both land on a pool device, but in the latter, the mover is involved, which may introduce other parameters.

I did state that the files are being transferred to an SSD ZFS mirror cache drive. 2025-07-21_10-02-35.mkv 2025-07-21_10-02-04.mkv

I've posted about disk throughput before, and I have seen a number of other posts about it as well. So, I'm back with another question, hoping to either come to an understanding of why it works this way or potentially expose an underlying issue. I have two Samsung 870 EVO drives in a ZFS mirror as a cache drive for a shared folder. Everything written to the share goes to the cache (obviously). My network backbone is 10G, although the UR server utilizes the MB's built-in 2.5G NIC. I was transferring a folder with a series of +12GB files over to the array, and the network transfer rate was about 30-40MB/s. Which is a far cry from 10G speeds. That's when I took a look at the UR dashboard to see transfer rates and disk throughput. The network throughput was showing approximately 600 Mb/s, and disk throughput was fluctuating between 0 and 170 MB/s. There was never a constant write speed to the cache drive for the shared folder. The mover is not running, and no other transfers were running in the background. If there are any tests I can run, please let me know. Diag attached. Thx, A.