ich777

Please post this in the Prometheus Support Thread here, I've only written the Guide on how to install it in conjunction with my plugins and I'm not the maintainer from the Prometheus container.

This is really strange, it looks like everything is working and initialized properly. Can you maybe also send over the transcoding log after starting a transcode?

Did you try it with Plex? Maybe also try it with Jellyfin. What is the output from: ls -la /dev/dri Can you upload your Diagnostics please? @always67 does it work on your machine?

Then something seems wrong with the network itself. Are you sure that everything is working correctly on this interface? Can you try to download another container and see if it has access to the internet. As said above there is nothing different than to the Barotrauma container and it does exactly work the same as the Barotrauma container in terms of downloading the game.

There is nothing different to the VRising container other than running it through WINE. What do you mean with crashes? If it is in for 17-18 seconds only the SteamCMD command is executed and it should download the game and there is nothing else going on like it is for Barotrauma. Can you maybe post the log?

Did you make sure that the card is actually working? Please also make sure that you are on the latest BIOS version, try to reseat the card in the PCIe slot, do you have IOMMU enabled in your BIOS? From what I see in your Diagnostics you are booting with UEFI, can you try to boot with Legacy (CSM) mode? I only can think of a HW compatibility issue. May I ask for what do you want to use the P2000 HW transcoding or something else too?

The Firmware files are already added to the TBS-OS package and should work without any modification.

How did you edit the file? I did it through Notepad in Windows, you even don't need to restart the container so that these settings apply.

May I ask what the correct folder is?

I've tested the Container a few days ago and it worked perfectly fine. The errors that you see on screen are usually caused by WINE but the container should run fine anyways. Have you yet tried to connect to it via direct connection?

With the patch applied since 6.10.0rc8 everything should work fine.

I have now installed the container and looking at the documentation you have created the file in the wrong folder: Click I can connect to RCON but I actually don't can't test it if everything is working because I have to set up my VR and I don't want to anymore because it's almost midnight over here. But what I can tell is that I don't get an error message like you do.

The adminlist.txt works only from the directory ".../VRisingServer_Data/StreamingAssets/Settings/adminlist.txt". I and also others on Discord that use my container can confirm that this is working (keep in mind, on a container update this file will be again be empty - this applies also if you have validation in the Docker template set to true). I've already created an issue on GitHub for the devs to fix so that it works at the directory: ".../save-data/Settings/adminlist.txt" where it should need to work here: Click

You also have to create a port mapping in the container. Click on "Add another Path, Porta, Varaible, Label or Device" from the drop down select "Port" at container and host port enter your RCON port that you've set (in your case I think it's "9100") & make sure that it's the protocol is set to TCP, click on "Add" and "Apply". Otherwise the port can't be reached.

Have you stopped the container in the first place, edited the file and then started it back up again? This is the first time I hear of a issue like this. I'm not really into ARK but I can look into it.

Did a bit more testing: Downgrading from 6.10.1 -> 6.9.2 (picture from before the upgrade): Upgarde from 6.9.2 -> 6.10.0 (picture from before the upgrade): The Plugin Update Helper fails on 6.10.0 because the Kernel version string is formatted wrong in this version but this is a good test because the plugin packages are not pre-downloaded like in your case and will be downloaded on boot. Upgarde from 6.10.0 -> 6.10.1 (picture from before the upgrade): You are completely correct that it falls back to latest. But finally set the version again to 470.94 and upgraded to 6.10.1 (picture after the upgrade): The reason why it resets the version back to latest is because the Plugin Update Helper fails but this shouldn't happen anymore in the upcoming version from Unraid because I've reported that the Kernel version string was formatted wrong to Tom and it should now be fixed. Thank you for the report! I will take a look to make the Kernel version detection even more robust.

I've tested it now, a little different and also the Plugin Update Helper was fixed too before I've done that: Downgraded to 6.9.2 Changed the driver version to 470.96 in the config file Triggered the update to 6.10.1 In this case the Plugin Update Helper downloaded 470.94 for 6.10.1 After the reboot to 6.10.1 The right version is installed The plugin (and also the Plugin Update Helper) should always honor the preferred driver version, I will do some more tests next week and report back. The driver only falls back to latest if it can't find the selected driver version, maybe the network was a little to late initialized on your machine, but that's only a really vague guess. Anyways, this shouldn't happen anymore because the plugin update is fixed now, but as said above you maybe have to reboot once more so that the new version is installed. Sorry for the inconvenience...

I will look into this ASAP and test this.

Fixed just now, should now work, you maybe have to reboot once so that the new plugin update script is installed.

Why? Please a detailed why…

To both things no... Seems like something messed up your config, but I don't think this was caused by an RC update or something like that.

Look at your acls there is a IQN in there with "linux" and you say that you want to connect from Windows, there is something wrong with your config. Windows usually has "microsoft" in there not "linux".

This should be correct, but try it again, maybe the old name is cached somewhere, you can always go through the logs and see what name is in there.

The same as for @Newtious, you have to specify the server name in the Docker container template because the start variables override the config file and that's what the server name in the template refers to.

Looking good to me, here is a screenshot from my system: I don't think that's necessary, I see you are trying to connect from a Linux initiator, maybe you have to turn off Authentication on that system or turn it on in iSCSI (but you have to do that through the command line if you really want to), for home use I would recommend to turn off Authentication.