aglyons

@JesterEE I wanted to touch on the features you asked for. Dashboard docker widget integration (Similar to FolderView3) I can look into this. Can you describe what you would want to see there? I think shoving all your services would get the dashboard cluttered pretty quick. Pinning specific items might be useful. But could operational statistics, resource graphs stuff like that, is that something that would be a good addition? Stack/Folder custom icons (Similar to FolderView3) The main stack icon, as it stands right now, is a tiled view of the defined services. If you set the service icons as you like, the stack icon will reflect a tiled composite of them. For folders, I hadn't considered changing the folder icon itself, but I can add that to the possibilities list. Notification/Automerge of an upstream docker compose environment (YAML, env files, etc.) modifications One of my biggest gripes with the current Unraid docker template system is that when a docker template is updated by the author, there is no way for a current user to easily merge the changes into the template deployed in Unraid. Staxx offers and infrastructure that could do this better while not compromising user modifications to the upstream configs. So StaXX does have automatic metadata and project example scanning along with automatic service icon pulling. It's by no means complete, as there's no defined standard. What it does is scan GitHub repos linked to the service, pull in the example compose file, and suggest items your current YAML is missing or items your YAML has that the examples don't. This covers new features that a repo might add to a project that require ENV vars or other accommodations in order to take advantage of. Another function is tracking when an image moves from one repository to another, such as when the source image used to be on Docker Hub but is now hosted under GHIO. It ensures it is the same author and doesn't just point you to some random image with the same name.

Hey @JesterEE , thanks for checking out the project. I hope this is all still relevant once UR8 is released, with them jumping into the compose situation as well. I addressed your concerns, all except one as I can't seem to replicate the problem. Folder Collapse/Expand arrows. They change on my system, and I've reviewed the code there as well. SO I can't explain why you're seeing that. In the future, submitting bugs or feature requests is best done on my board: https://staxxfb.quadcom.ca/. You can paste screenshots directly into posts, which seems difficult, if not impossible, on these boards. I'll be working on adding in-app bug reporting soon that will make the process even simpler. Again, thanks for checking Staxx out. I also really appreciate the feedback and the review!

So the plugin has been on the Unraid CA for a little while now, and I see that there have been some people downloading it, so that's always cool to see. https://ca.unraid.net/apps/staxx-0626nzk0azbrks I would love to hear feedback from people: what they love, what they hate, and what they'd like to see different. Feedback is always great to hear. While you can write stuff in this thread. I'll check it from time to time. If there is something very pressing, then by all means post a card up on my bug tracker/feature tracker that's dedicated to Staxx. https://staxxfb.quadcom.ca/ I really hope this is a plugin that people find useful and really come to like.

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.

I think what you're really looking for is not really multiple arrays, but a cache pool for the existing array. None of the arrays (other than a ZFS AFAIK) have any striping, so you wouldn't see any real performance benefits with an array of NVME drives. I think you might even see a performance degradation (compared to single mounted NVME) as the array functions require all disk activity when writing to a disk in order to calculate the parity bits. That is the reason Unraid arrays don't have spectacular throughput performance and the addition of cache pools to speed up writing and reading (in certain configs).

I don't think disabling IPV6 or anything else does it. I suspect that once UR is up, making any change in the config resets the networking, and the SHIM gets created as it should. I myself had the default bridge disabled, and when I re-enabled bridging on the ETH0, everything started working. But I have seen many other people saying they enabled this or disabled that, and it started working again. I really think the problem is rooted in the boot-up process and the creation of the network at boot-up. Perhaps the SHIM creation process is run before another function that is required for the SHIM, in which case, the SHIM creation would fail. But once the system is up, changes to the networking runs the SHIM process again, and because all the other functions are already in place, the SHIM is created correctly. Again, this is all theory. I don't possess the required Linux acumen to diagnose this fully.

Thanks @bmartino1 and @ChrisCross Regarding the IP address to assign, is that for the host network or the VLAN? If it's the host network, is that not going to add another IP to the host machine on the same host network? I already have Unifi complaining on the regular about two devices having the same IP; now it appears that we are adding a third IP for one box!? @limetech This is an example of the community trying to help solve these issues, but there is a lack of clarity and an introduction of third-party code to solve a bug that could cause complications should the following release address this issue from another direction. If there is an official patch that works, either broadcast that out in an email to paid users or release the 7.1.3 release with this in place.

Is this script universal, or does it need customizing to work? My box has both bridging and bonding disabled, VLANs, and custom bridges in place. Also, my IP base is different from the script. I couldn't see any specific walkthrough of customizing the script to suit a system's config, and I would like to avoid killing my network connectivity completely. Any chance of getting a walkthrough on what needs to be customized?

And a fourth. https://forums.unraid.net/topic/189927-solved-710-host-access-to-custom-networks-no-longer-works/ The posted 'solution' does not read as a real solution but rather a temporary patch. It is a series of steps that must be performed after each system reboot, so the 'fix' is not persistent.

I just ran into this issue and have found two others that I suspect are the same issue. https://forums.unraid.net/topic/190305-712-docker-vlan-host-comms-broken/

I suspect that we are seeing the same issue. So far, I have found one other besides myself and this post. https://forums.unraid.net/topic/190305-712-docker-vlan-host-comms-broken/ In my case, nothing was changed in the networking or Docker config prior to or following the 7.1.1 or 7.1.2 updates, and it has been working with the same configuration since 6.12.