cinsun42

Just thought I'd bump this because I'm having the same issue with the bambu studio linuxserver container. I use a reverse proxy for all my internal https access, so making the change over to port 3001 wasn't a big issue. With the latest update, I get a mixed bag of issues depending on what OS and/or browser I'm using - I have no clue where to start. These are the issues for each scenario: linux mint 22.2 - google chrome: continuous cycle of alternating between "waiting for stream" and "a critical video error occured. resetting to default settings and reloading" linux mint 22.2 - firefox: it works! linux mint 22.2 - opera: stuck on "waiting for stream" windows 10 - google chrome: it works! I am using my intel igpu and have the latest intel gpu drivers installed on unraid. I'm assuming by the mixed bag of results above, there must be some sort of video rendering issue within each browser

I just updated Unraid Connect to version 2025.09.05.0026. I am on Unraid version 6.12.15. I did not receive any errors during install, everything seemed to run successfully. I am accessing the server GUI through Chrome. Upon restarting my server, I did have to re-login into the connect plugin and re-attach my server to my account for some reason. I've also noticed that clicking the "Settings" button within the Connect menu doesn't do anything The primary issue is that sometimes the Connect button that opens the drop-down menu just disappears, along with the server version number. I can get it to re-appear by clicking on a separate page, or by re-loading the page entirely. I've attached two screenshots for reference

I'm on Unraid 6.12.15 and the latest plugin version (2025.05.04) This plugin was working just fine for me, but I think after one of the more recent updates within the past few months some functionality has broken for me. I have not really changed any settings, but files do not seem to be moving off my cache pool as expected. To start, I enabled mover logging, mover tuner logging, mover tuning debug logging, and test mode. This is the only output I see in syslog: May 16 08:20:39 unRAID move: Mover Tuning Plugin version 2025.05.04 May 16 08:20:39 unRAID move: May 16 08:20:39 unRAID move: Usage: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start [-e <disk_name>] May 16 08:20:39 unRAID move: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover stop|softstop|status|reset May 16 08:20:39 unRAID move: <disk_name> must match pattern 'disk[0-9]*' May 16 08:20:39 unRAID move: May 16 08:20:39 unRAID move: reset - reset config file to default values and delete override config folder Additionally, If I look for any mover tuning logs within /tmp, I'm unable to find anything. It seems mover tuner is not properly executing, but I can't be sure. I'm attaching screenshots of my current mover tuning settings for reference. Any thoughts on where I can start digging for a solution? Many thanks in advance!

I've also updated to the latest and noticed that my printer no longer shows up on my network via Airprint. There have been two updates within the last month, I'm not sure which one has broken functionality. I'm going to try downgrading the container and I will report back EDIT: Downgraded the container to 1.1.5 and everything seems to be working fine now

Hi @binhex, I'm trying to enable https access to the sabnzbd web server, but I can't seem to change the default HTTPS port from 8090. Even if I change this value, it reverts to port 8090 when the container is restarted. 8090 doesn't seem to be mapped in the docker configuration and I suppose I could do this myself, but was hoping I could just set it to 8080 (the default webserver port) and call it a day. Is there a particular reason why this port keeps reverting, or am I going about this all wrong?

We experienced a power outage yesterday and the NUT plugin failed to execute a safe shutdown sequence but fortunately I was home to take care of it. I've attached syslog notifications showing the sequence of events, but to provide some context we initially had the power go out for a few seconds, come back on for 3-4 seconds, then finally going off again continuously for about 2 hours. The nut plugin showed the system was on battery power and even gave an alert twice that it was going to start the shutdown sequence in 360 seconds (I have unraid set to shutdown 6 minutes after going on battery, NUT settings shown below). There was notification that the initial shutdown sequence would be cancelled, but you can see that a secondary sequence was started immediately afterwards. I'm wondering if there was some timing issue where both shutdown sequences were cancelled while still on battery power. Ultimately NUT did not start start a shutdown sequence and I had to safely shutdown everything manually. Any thoughts on a more robust method for ensuring this doesn't happen? Regarding the attached images (specifically syslog), the initial power loss was on the 26th at the start of the log shown. The shutdown sequence at the end of the log on the 27th was me testing to make sure NUT was behaving as expected with a "normal" power loss scenario - I just pulled the UPS plug and NUT shut everything down safely as expected.

I wanted to make this post before submitting a bug ticket, not knowing whether or not this is expected behavior. I have a container "binhex-nzbhydra2" which I route through a separate VPN enabled container "binhex-sabnzbdvpn". Generally speaking this seems to be working fine and I'm not aware of any issues such as IP leak or connectivity problems. I used the guide created by spaceinvaderone that was linked here to accomplish this: All this said, I have noticed that when I install or update another container unrelated to nzbhydra2, it will inherit the port mappings of that container in the GUI. I believe this may only be a visual error but without 100% certainty, as I'm still able to access the nzbhydra container via the ip and port that are established by sabnzbd. The example below demonstrates the issue, I just updated the tautulli container and the port mappings for nzbhydra2 show the same (usually this field is blank).

So I did end up making the change to only the share name ("TV Shows" to "TV_Shows") and it seems to work with all underlying files! Many thanks! Now I have a follow up question. I did a trial run in test mode and without going into all the details it definitely looks like it wants to move the files I most recently moved onto my cache pool, instead of the much older (up to 3 months) worth of data. I'm talking about things that have been moved onto cache within the past week. I'm using the 'Auto' setting for moving files based on age. Any thoughts why this would be happening? I was expecting the opposite behavior EDIT: I think I've answered my own question. Many of the files don't have recent modification dates, despite being transferred recently. I'd probably need to make more deliberate attempts to re-name files (or similar) to reset the modification date.

Is it just the share name, or would it need to be all underlying files and folders as well? I think I can probably handle making an adjustment to the share name and re-directing all related dockers/plugins, but if files/folders need the same its sort of a non-starter

I'm running into an issue with this plugin, I assume, not correctly escaping a "space" in my "TV Shows" share name, thus producing an error (see attached). I searched for this topic and found some others who have experienced similar issues recently with "special characters". The advice given seems to be renaming shares or filenames, which frankly is not an option I'd like to consider at this point - primarily due to breaking other functionality. Is there really no other solution than re-naming shares/folder/filenames? I've used older iterations of this plugin that did not have the same problem, so I'm just curious what may have changed that would be causing this. I'm very appreciative of the functionality this plugin can provide, so I hope there are alternative solutions to this issue. Many thanks!

Thanks @binhex for another great container! Its an easy decision for me to select your variants every time I install a new app. This is my first time routing a separate docker container through one of your VPN enabled containers. Specifically, I'll be routing nzbhydra through sabnzbd and would like for the ability of those two containers to "talk" to one another (sending nzb's directly to sabnzbd for example). Generally speaking, I understand the process of either enabling Privoxy and configuring proxy settings within nzbhydra, or simply routing nzbhydra directly through sabnzbd's network by editing the docker config. That said, Is there a clear advantage of using one method vs the other?

I fixed it! To start, yes I do have a remote syslog server running. While that wasn't exactly the culprit, the fact that you mentioned it along with the syslogd configuration had me digging through all my syslog config files. It turns out there was a bug in how rsyslog.conf was written sometime before unraid 6.9.x (issue linked below), which would inadvertently reset the filtering rules after custom rules has been applied. After deleting rsyslog.conf and rsyslog.cfg from flash, the files were recreated properly after accessing the syslog configuration in settings. The filters are now working! Thanks again for the support, there's no way I would have sorted this out through blind troubleshooting.

Here you go, thank you!

Welp, I don't want to waste your time with any of this. I ended up trying a different USB cable on a whim and those errors have stopped it seems. That said, it does seem like the ability to suppress the syslog errors is not working for me, but I guess I won't worry about that until the need arises. Thanks again for your help! EDIT AGAIN: I spoke too soon. I'm now getting a bunch of the data stale messages, but as stated previously it does not seem like the syslog filtering function is working for me. Screenshot attached for ref

Unfortunately this doesn't seem to have worked for me, I'm still getting the same errors populating in syslog. This is after adding the lines above and restarting NUT several times with Enable Rule-Based Syslog Filters: "Yes" Some things I've noticed that may or may (or may not) be helpful: when I was originally trying to add my own filter rules to "xnut-nospam.conf" I was getting syntax errors upon NUT start-up, presumably because what I was adding was wrong. After adding the lines you suggested above, I no longer receive those errors so that is a good sign I've looked for the /var/log/nut-spam file through Krusader and I simply can't find it. I had NUT running overnight with "Enable Rule-Based Syslog Filters" set to Yes, so I would have at least expected the file to have been created. Is it possible there might be some sort of permission issue that's preventing any of these lines from executing? Attaching my current xnut-nospam.conf for reference. Thanks again for the help! EDIT: adding an additional screenshot of "errors". I believe some of these should be captured by the filters in xnut-nospam.conf which seems to indicate that none of the filters are working in my case