ich777

In my oppinion it‘s up to the maintainer to mark a path as required in the template which is empty to force the user to either specify a path or remove the path from the template. The same applies to devices that may be empty in the template, they should be also be marked by the maintainer from the template as required so that the user is, again, forced to fill it out or remove the device entry.

Most people still run it on consumer hardware hut with parts from servers that are available for cheap on ebay and so on. But it is really hard to build such a hardware database sonce it can be also the case that some components work with sleep on one system and on the next it won‘t work because a firmware bug exists on one system and on the next not whcih is maybe fixed with a newer BIOS/firmware,… Not sure if many users will install/opt in to such a plugin becuase you are basically collecting data and not everyone is willing to do so because you need certain things to identify the system to not include it twice in the database. I thought a few times about that but it can be a nightmare in terms of a databreach and got hacked. Sorry but isnmt that a completelly different topic, I thought you where asking about the S3 plugin. However if the plugin is working as expected you can still use it. EDIT: I‘m not sure if Proxmox or TrueNAS has such a feature but I can‘t imagine that (sorry can‘t give a definitive answer about that systems because I don‘t use/know them). EDIT2: After reading the other thread I know that you want to see more action but have you seen that the plugin is from Dynamics and so to speak well maintained and almost a part of Unraid. From what I can tell you are more worried that the plugin disappears at one point or isn‘t supported anymore correct? Even if Dynamix disappears (what I really really can‘t imagine) someone else is able to fork the plugin and continue his work. That‘s the beauty of plugins. As an example I have just found a users who will now continue the support and maintain the Intel iGPU SRIOV driver plugin where the maintainer dissapeared. We are a really good community here and we help each other as good as we can, sure I‘m also not a fan of the S3 Sleep plugin because of the above said reasons but many people use it and someone will support it, but as said I don‘t think that Dynamics will disappear because he is almost part of the OS. 😉

I'm in the same boat as @primeval_god. It should be always be a plugin because sleep is nothing that should be used on a server in my opinion, a server, even if it's a home server is meant to run all the time and be as stable as possible. With sleep you are introducing so much different variables and maybe instability. Not every device is waking up properly or is in a semi sleep state sometimes this is especially as @primeval_god pointed out the case often times with real server hardware because in a server farm sleep is not even considered as a feature. Of course consumer hardware has also some times its quirks and a component can also be in a semi sleep state or even won't wake up at all. Even on Windows Sleep is not working properly on some machines (you'll find many posts about that on your favorite search engine). You always have to keep in mind that only because it is working for you it doesn't mean that it is working for everyone. If the plugin is working just fine then why not use it as is? Thanks for calling me dumb... 😭

Nice. Do you have any issues? What is the question? If you have no issues, leave it as it is. Are you sure it is not under Plugin Errors in the Plugin tab in the Unraid WebUI?

Is everything working? If yes then no. If not then yes. I think you've answered your question yourself since only one matches your model number:

Please do the following: Place the two attached files somewhere on your server Open up a Unraid terminal Navigate to the folder where you've placed the files Issue the command: installpkg corefreq_INTEL-develop-x86_64-1.txz Go to the plugin page and try to retest and see if it now loads fine. Let us know how it went. Feel free to reach out if you have further questions. corefreq_INTEL-develop-x86_64-1.txz corefreq_INTEL-develop-x86_64-1.txz.md5

@bmartino1 yes, these are the steps to mount a path from the hsot to the container, like you can do it for Docker with a bind mount.

Did I link the wrong post, it should have described how to make a host path mount into the container, so to speak mount a path from Unraid directly into the container itself via the LXC config from the container.

Please mark that as maybe necessary if users have issues setting up the first container since this happens not to all users. I have a question about the MAC address here... why does it look like that? The MAC address is generated randomly and automatically if you add a container. You could also mount a path directly from Unraid if you want to like described here: (Please note that it's not typo that there is no starting / for the path in the container)

That always depends, usually game servers don't need to be owned and the container downloads them using the anonymous account to download it from Steam Pipe. I would recommend starting over. Delete the container, delete the palworld folder that lives in your appdata directory, pull a fresh copy from the CA App, change nothing in the template and click Apply. You usually don't have to do anything unless the template or the description from the template says something else or to add a parameter but for Palworld you can simply deploy the container and you are good to go.

Please read that post, starting from the second paragraph where I explain that a bit more: A game server won't answer to such sites and therefore the site lists that the port is closed. What is not working exactly? From your screenshot I see that the server is running and waiting for connections.

I don't understand, did you try this on an already installed container? If yes, that won't work. According to that guide it is only a matter of changing the App ID: ...and that's exactly what my container does. EDIT: I just tried it out of curiosity. However it seems now that you have to log in for whatever reason to get the stable branch version which is really a dumb move in my opinion: However I would recommend that you create a second Steam Account for that purposes (this is also the recommended way from Steam) buy a really cheap game in that account, disable Steam Guard entirely and use a very strong password for that account. After you did that you can then use that second account for the container. As you can see above it is running fine. EDIT2: Anyways, I don't know if I'll change the template, maybe I deprecate the container since this is rather complicated with a dedicated account and I would encourage no one to use his primary steam account without steam guard.

I think the best way to fix that all is to start over... Delete the container, delete the palworld directory in your appdata folder and pull a fresh copy from the CA App, there you will see the backup option. I assume you have a really old template that you didn't see the Backup variables in there.

I don't understand, it's already there: This is the official server, of course the experimental one with App ID: 1042420, because I don't see the other DayZ server already supporting Linux App ID: 223350 But if you want to you can simply change the App ID in the template, this should do the trick if it is already released. I won't make a new dedicated server because I simply can't take any game server requests with almost 200 apps on the CA App, but you can let me know if it is working by changing the App ID.

This is usually a indication that a Docker port is allocated twice or the image itself became corrupt. Please go in the template, change something, then change it back to like it was before (you have to do this to activate the Apply button) and then click the Apply botton. On the next page wait until the Done button appears but don't click Done and post the docker run output here, or you could fix it since you will then see why it was failing. Hope that helps.

I don't think that this is a firmware issue from the VMs... I already saw your posts and waited for your post here... I'm not too sure what the exact issue here is because I don't have any suitable hardware to test the SR-IOV plugin. Maybe @SimonF has a clue.

Please post your Diagnostics.

The issue with this approach is that the plugin is intended for Docker usage and not for Docker and VM usage, this is simply not supported. The tutorial that you've posted is also missing the USE AT YOUR OWN RISK section because users will definitely ask why their server crashed because they forgot to kill nvidia-persistneced or any other circumstances, there are a few other scenarios where you could crash the server btw... This has nothing with my personal preference to do. You have to understand if I write that down, someone at some point will create a post and say that he lost data because of that and maybe this was critical data for themselves, TBH all data from a user is critical in my opinion. I simply don't support that and I won't document that because this is not the use case of this plugin. Please copy past the tutorial in the VM subforums because it is related to a VM and not for the intended use case. You can link to your post here if you want to but this is nothing that I can/will actively support/document.

Nice, glad to hear. I actually added the firmware to the new driver packages so to speak, you will have no issues with Unraid 6.12.8+ If you experience any further issues please let me know.

BTW you can see all the latest driver versions for the various driver branches from Unix here.

I strongly disagree about adding that to the documentation! This is not how the plugin is intended to be used in any way. For most users this will basically mean that they crash the server and potential data loss and this is a big reason why I don't want to add that to the documentation. Please post your tutorial somewhere other than this thread (maybe in the VM subforums) because I don't want to support that in any way, I made this also clear in the first post of this thread. BTW, this can be simplified with that: kill $(pidof nvidia-persistenced) For most users this is also not needed, this depends always on the hardware.

The plugin is the same and I'm still compiling the plugin packages for this new plugin for @giganode. Uninstall my plugin Shutdown all VMs Install the plugin from the CA App Recreate your VFs Check the configurations in your VMs if everything is correct Use as usual It is basically the same as you switched over first from the very first plugin to my plugin. The change was done since I don't have any hardware that supports Intel iGPU SR-IOV, this was also the reason why I haven't published in the CA App. Thanks to @giganode for his contributions and continuing with the plugin and support for the plugin.

Where is the card visible on the plugin page? Do you use Plex or TVheadend? I see 4 tuners in your recognized in your Diagnostics. What is the output from: ls -la /dev/dvb Can you post a screenshot from the plugin page with the TBS driver package installed please? Please upgrade to Unraid 6.12.8 before we continuing further troubleshooting and include new Diagnostics in the post after the upgrade.

It sounds like you are trying this in the web browser correct? Please try a native Plex app like Android or iOS, the web app is known to have issues when forcing a transcode and just display a black screen.

You can ask here but I usually put everything into the descriptions from the variables and I‘m sorry to say that but I’m tired of Palworld now. This is such an unoptimized game. I saw RAM usage of about nearly 40GB on my server with 9 concurrent players. 😂 …and there is nothing I can do about that…