ich777

The main issue with that is, when the container restarts all the containers which are routed through the container need to be restarted too and that's why I came up with that idea "Connected Containers". I just need the container names and from which repository/maintainer since I have to look into if that can be implemented easily, if you are using my *arr containers then it is pretty simple.

Please check the variable in the container, it seems to be set incorrectly to "lastest" instead of "latest". It should look like that:

I will look into that, please give me a few days.

Funny story, I just implemented a ping check yesterday so the container auto restarts when the connection is lost and I even implemented something that I call Connected Containers so that if the VPN container is restarted for whatever reason, compatible containers with Connected Containers will restart too. To enable the ping check create a variable in the template: Key: PING_IP Value: 8.8.8.8 (you can choose another host to ping too but please make sure that this host is reachable when the VPN is running) You can also specify a second variable in the template to specify the interval: Key: PING_INTERVAL Value: 300 (value must be in seconds, I think 5 minutes is a good value) But keep in mind that you have to restart the containers that are routed through the VPN container are also need to restart that's why I came up with the Connected Containers idea. For the connected containers feature I would have to know which containers you are routing through the VPN and from which repository so that I can tell you what to do, I'm still evaluating that feature but it is working perfectly fine over here.

Könntet ihr mal bitte eure Diagnostics posten? Too little information to say anything...

Go into the BIOS and enable Multi Monitor Support (it may be called slightly differently in your BIOS), this should enable your iGPU even when you have a dGPU installed.

Sure thing, but I don't linked it here in the thread. Just look over here.

Pleas install the GPU Statistics plugin, the Nvidia Driver plugin alone is not responsible for showing the GPU Statistics. As for your second issue this seems more container related since the driver is recognized fine. Are you sure you are forcing a transcode within Plex (please don‘t use the web player since it is known to not work properly when forcing a transcode instaed use a native client for iOS, Android,…)?

Diagnostics would help too...

Please update the container, this should now be fixed.

I assume you are not running the container on Unraid or do you? It seems that you've stopped the container once while it was still downloading the runtime, could that be the case? Please delete the runtime folder and restart the container and see if that fixes the issue.

Exactly, just put in the key and your IP/domain name at ID and Relay server in the connection settings and that‘s it. Your clients should be then able to connect to each other with their IDs and passwords (you can set static passwords too if you need them). The API server is only available in the pro version but you don‘t need it strictly speaking.

Thank you for the report, I will look into that and report back. EDIT: See 2 posts below.

What do you mean with the web client? This container is not the pro version and therefore it has no webclient. For the free version you have to use the individual clients on your machines and they can connect to each other throught the server with your key that is displayed in the log file.

Can you share a bit more information please? Do you use the card in a VM or are you talking about a physical (maybe different) Windows machine? If you are talking about the card beeing in Unraid and working in a VM, is the card bound to VFIO? Diagnostics would help a lot.

This is nothing to worry about and has nothing to do with the Nvidia Driver plugin. You have set a custom system memory limit from 16G for the container and Docker itself is complaining that no swap is found basically <- on Unraid there is no swap partition. What do you mean with that, the driver is working perfectly fine alongside with transcoding. You should really read the second post in this thread.

Bitte poste mal deine Diagnostics.

Correct me if I'm wrong but that is Windows (and maybe MAC) only correct?

What is the benefit over TVHeadend?

Sorry but I no longer use MagicMirror² and I might be deprecating this container in the near future since another user also stated that a installation from a module won't work properly because the module needed a few extra steps which the container does not support by default. I guess you could set up a LXC container and install MagicMirror² in there, that's your best bet. Sorry for not having better news but I have a few containers that I'm not fully satisfied with anymore and I might deprecate.

@Greg Inferno where you able to resolve your issue with Satisfactory?

The first and the last game servers are based on Unreal Engine 5 and I'm actually not 100% sure if they expose themselves properly in the SteamServer Browser, you have to understand that only most Unreal Engine 4 games and surely all Source and Gold Source are usually exposed properly. For RUST I'm not 100% sure if it exposes itself to Steam properly. So in conclusion not all games will show up in the SteamServer Browser and especially not in the LAN tab and it is not even a requirement from Steam that the dedicated servers must show up in the SteamServer Browser. Sure for each game it is different but usually you will be able to join to the in game server browser and join like that, if your NAT Reflection is working properly you should be also be able to see and also join from within your LAN <- if NAT reflection is not working properly you will be only able to join from outside your LAN with your public IP or the entry in the in game server list or from within your LAN with your internal IP. Hope that makes sense.

As @Kilrah already pointed out, don't use NPM. NPM is only for http/https traffic, sure if you are using streaming ports it will work but what is the benefit because you would have to also open up ports and a streaming port in NPM is basically the same as if you directly point to the container IP address. My recommendation is: simply forward the ports in your Firewall from the RustDesk container and that's it. After that you can connect with your domain name to your RustDesk Sever. What you are doing in NPM can't work because you are streaming the ports which would also involve opening the ports but I would not recommend doing that because you are overcomplicating your set up for no reason.

I remove the file if it is found on container start up.

Can you please use the correct support thread here: @jmztaylor is it okay for you to Lock this thread with a short message and link to the support thread? You can also look at this post where a user was having the exact same issue as you two: Are you really sure that your NAT reflection is working properly on your network since otherwise you won't be able to connect from your LAN to RustDesk but if you connect from outside it will work fine.