Xoron

Hope this helps. I run my subgen networking through another docker image. So that part might be different for you.

That's exactly what bazarr is for. to download (or in this case generate) subtitles on videos. You should seriously look at bazarr to do that for you.

Ok, now you've peaked my interest. What exactly are you using it with Plex for?

I abandoned whisper ASR and went with subgen (https://github.com/McCloudS/subgen). And it's been working fine ever since You just use whisper asr in the bazarr setup, and point it at port 9000 for subgen

Sorry for the late reply Everthing is working exactly as expected. My setup is fairly basic. But you can always just export the config, shutdown the old docker, start the new one, import the config. If things go sideways, you can always revert back to the old docker.

Shout out to @PeteAsking for this docker. I was running a quite old version of Unifi Controller docker version 7.2.92. The recommended upgrade path was to install the same version of this docker, but none that old exists. Figured, why not, lets go for the newest stable version of unifi-controller-reborn, see if that will fly. I backed up my config on my v7.2.92 controller and powered it off. Then I deployed version 9.4.19 of unifi-controller-reborn and the backup restored fine. Logged in with my original credentials. All APs were present, historical logs, everything. Smoothest upgrade I've ever done.

I've setup deluge vpn docker, and have all of my arrs running through it fine. I did this back in the 6.9 days of unraid, so each of those dockers routing through deluge have the --net=container:binhex-delugevpn parameter. Now I've decide to take a look at SABnzdb for usenet. I want to route it thorough my deluge vpn docker as well. The default port for SABnzdb is 8080, which another docker currently uses. So I want to set it to be port 8085 (or whatever free port there is). On the SABnzdb docker, I've set the Port: Web Interface to 8085. On Deluge, I've added that port to the various variable that require it (same as my other dockers). But I cannot get the SABnzdb GUI to load. I even went so far as to try and modify the /mnt/user/appdata/binhex-sabnzbd/sabnzbd.ini file (with the docker off) to use port 8085 (port = 8085). But every time I start the docker, the config file reverts the port back to 8080. I must be missing something with the config. The SAB docker should be able to route through delugevpn. Looking for suggestions on what to try next.

So I've made some progress. I was able to get whisper-asr-webservice to see and attempt to use my GPU, but doesn't seem like it's using the decoded/encoder engine. My original problem was that when you want to use the GPU (--gpus all which is on by default), I had to use the specific repository that calls the compatible docker. onerahmet/openai-whisper-asr-webservice:latest-gpu But now when Bazarr tries to generate subtitles for videos, it never completes it, and the GPU sits idle, all while using up loads of memory:

The whisper-asr-webservice doesn't have an official support thread, so posting here. Mods: feel free to relocate to a more appropriate forum. I've deployed the whisper-asr-webservice from the community apps as a docker container. My goal is to have it perform sub creation via Bazarr. I have Bazarr and Whisper talking, and it will generate subs, but only using my CPU. From the documentation, I needed to have the --gpus all extra parameter set. (which it is by default). But with that setting, it's still using the CPU. I've even setup the NVIDIA_VISIBLE_DEVICES and NVIDIA_VISIBLE_DEVICES variables (with the same values that I have set for my other dockers), but still uses CPU. I also added the extra parameter: --runtime=nvidia but still can't get it to use the GPU I'm sort of at a loss on what to try next.

I resolved my issue by looking deep into the deluge logs. First, I was getting an error that /config/ssl/daemon.cert could not be read. It has permissions of 600 and was owned by root:root. I changed permissions to 666 on the file. chmod 666 /config/ssl/daemon.* Next it was throwing the same error in /config/auth. So I performed the same chmod on it chmod 666 /config/auth Now I no longer get the never get the error below, and the GUI loads correctly: [info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846...

I'm having the same deluge no WebUi issue since updating to 6.11.5 today. I too am using Mullvad VPN for the docker image. I'm getting the same exact message in the logs that I've seen mentioned elsewhere [info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846... What I've tried so far Force Updating the Deluge VPN Container Removing the container, and reinstalling it Generated a new Mullvad OVPN file Changed DNS servers around in the Container config I think my VPN is actually up, just the WebUI for Deluge won't load. I can actually access the Web UI of my other dockers that I route through Deluge VPN. Following this thread for a solution.

Thanks to @JorgeB for pointing me to this thread, and to @Cessquill for the good work finding, working in, and resolving this obscure issue. It's plagued me for a few months (and I was away traveling, so I was hoping I wouldn't drop my array while away. Simple change, reboot, all good.

Thanks for pointing me to that thread @JorgeB. I had searched the forums, but didn't stumble on it myself.

I have two Ironwolf ST8000VN004 7200RPM drives as my Parity Drives. One is less about 9 months old, the the other about 4 months old. Both drives are throwing errors. I've precleared each drive, without any errors Replaced the SATA cable (SFF-8087) that is connected to both drives. Run an extended SMART self test on one of the drives, no errors detected Looking at the smart data, there are no apparent SMART values out of whack I reviewed the diagnostics for the drive, but nothing obvious jumps out. (Attached for review) Looking for suggestions on what might be wrong, and what to look at next to fix this issue (If it's a false error, then suppress it.)

I'm having a similar issue with my WD 8TB IronWolf 7200RPM Drives. Now I see that the read error, really isn't an error. BUT it's throwing errors on the GUI and I'm getting alerts that the drive is failing. Other than disabling the alerts (which I'd rather not do), is there a way to have unraid return the correct value.

I have the same exact problem. My main network is 10.168.10.0/24 which on my unraid box is on the br0 interface. As well, I have interfaces for non-internet accessible VLans (br2, br2.200). Whenever I reboot, unraid changes my default route to the 10.168.200.1 IP address on the br2.00 vlan interface. I can add a default route to the 10.168.10.1 address using the GUI, but I can't remove the default one on br2.200. I have to SSH in and run the command root@Nas:~# route del -net 0.0.0.0 gw 10.168.200.1 This happens on every reboot, with no way to have the default I set stick to 10.168.10.1 after a reboot.

Well, I've figured out the issue, and it was network related. Somehow, on a recent reboot of my unraid server, it set my default gateway to my DMZ interface's Default gateway. Of course, my DMZ has much tighter rules, and didn't allow outbound traffic to the internet on ports 1194/1195/1300, so the tunnel would never come up. Changed the default route to the correct network segment, and boom, tunnel came up. @Binhex, thanks for pointing me at it being a networking issue.

@Binhex thanks fro the quick reply. I've downloaded the config files from Mullvad multiple times, and the same servers are in the config file, but with different ports all the time. (I've seen 1195, 1197, 1300), so this leads me to believe that Mullvad has multiple ports open. Again, I've used the identical config files on my PC's OpenVPN client, and connected without issue. So I think the openvpn file is correct. That being said, I did manually modify the config file to use port 1194, but same results. It's possible that this is some sort of unraid networking / firewall issue. I've got the delugevpn docker setup in Bridged mode (which from what I've read looks to be the preferred choice). Does this mean that the traffic, from deluge, hitting my firewall would be the same IP as my unraid server? (Want to see if something strange is happening on the firewall side).

First: @binhex, thanks for all the work you put into your dockers and the support you offer on this forum. Forum users, looking for help with a VPN issue I'm having. I had delugevpn setup and working for months with my VPN provider (Mullvad) using openvpn. It's been working great up until now. But since a recent server shutdown, I can't get the VPN tunnel to work in the docker + I can't access the deluge gui. I'm at a loss to what the issue is. What I've done so far (with no success): When I set the Container Variable: VPN_ENABLED to NO, I can then access the GUI on port 8112. Downloaded and implemented a new config file for openvpn from Mullvad I've confirmed the openvpn config file by using the exact same config file in my openvpn client on my PC. So I know the file is structured correctly. As well, my PC and Unraid server are on the same network segment, and have the same firewall rules applied to both. Tried using Mullvad VPN servers in another region Pulled an older version of the docker to see if openvpn 2.5.5 client was the issue. (binhex/arch-delugevpn:2.0.4-2-01) Running ifconfig from inside the docker, I don't see tun0 up (which I think is the correct interface for the VPN tunnel) I've completely wiped the docker, cleaned up the files in appdata and pulled the full delugevpn again. I've stopped and restarted docker services on my unraid server. I've looked over the supervisord.log so many times, I don't see any errors or anything that could explain why the tunnel isn't coming up (See the attached supervisord.log file) What am I missing / what else can I look at to see why this isn't working? supervisord.log

I've been running the Cloudberry Docker, backing up to a Backblaze bucket for a while now. But I am missing files and folders from my B2 bucket. I purchased the Linux license of CB, and I'm only trying to backup about 600G of data (well under the limit of the license I have). I've had a look at the settings on CB, but everything looks like it's configured correctly. Below is the retention policy of the backup job, which overrides the global settings: NOT CONFIGURED to delete any files automatically. Keep 3 versions of each file Delete files that have been deleted locally after 30 days My B2 Bucket is configured to keep all versions of the file (IE allow CB to manage it) Yet, with these settings, I'm still not seeing all of my folders backed up. Is this a bad config, or is CB just that unreliable?