-MaNIaC-

I pulled the new image and waited for the first backup. Works! Thanks for the update! PS: I closed the issue in Github.

I opened an issue in your Github regarding minor error the Bedrock-Server Docker. After thinking about it I thought it would make sense to write it here in the forum: After looking through my logs I noticed that during the execution of the backups the script is not able to confirm the final command from the console: "save resume": 2022-02-08 17:24:52,102 DEBG 'backup-script' stdout output: [info] Waiting for Minecraft console message 'Changes to the level are resumed', 5 retries left... 2022-02-08 17:25:02,109 DEBG 'backup-script' stdout output: [info] Waiting for Minecraft console message 'Changes to the level are resumed', 4 retries left... 2022-02-08 17:25:12,115 DEBG 'backup-script' stdout output: [info] Waiting for Minecraft console message 'Changes to the level are resumed', 3 retries left... 2022-02-08 17:25:22,122 DEBG 'backup-script' stdout output: [info] Waiting for Minecraft console message 'Changes to the level are resumed', 2 retries left... 2022-02-08 17:25:32,129 DEBG 'backup-script' stdout output: [info] Waiting for Minecraft console message 'Changes to the level are resumed', 1 retries left... 2022-02-08 17:25:42,135 DEBG 'backup-script' stdout output: [warn] Minecraft console did not confirm message 'Changes to the level are resumed', giving up waiting... [info] Minecraft worlds backup complete Since the actual backup was successfull I ignored it for a while, but now after checking I found the issue: The message that it is checking for "Changes to the level are resumed" has been changed with version 1.18.0.2 of BDS to "Changes to the world are resumed".

Hi bonienl, first post in the Forums, lets see how I fare. I've been playing around with a few of your plugins and noticed some things in one of them: Specifically the Autofan: Im using an old Supermicro X8DTN+, the plugin is able to recognize the correct fan input and pwm device (In case of the X8DTN+ there are 8 Fan headers and they seem to all be controlled by one pwm controller: w83795adg). So far so good. Problem that i've experienced was that I was wondering why the fans were always going full throttle, even though the plugin kept changing the Input values. Found out a while later. The actual script doing the work ( /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/autofan ) has a nice variable called PWM_HIGH which is set to a standard of 255. In case of the "w83795adg" that max pwm input seems to be around 150. Now it made sense why the fans always ramped up to full speed, since that value is used to calculate how the fans are set. Changed that manually in the above mentioned script and look here, now the fans are properly controlled. But I am quite sure that the setting is gone after a reboot (since its created via the *.tgx from the plugin). I don't want to modify that since that modification will be gone if there is an update from your side. Do you think you could add the setting for that to the settings page? Could also be interesting for people that want to limit the max speed of their fans for noise reasons. Until then I'll maybe write a small script for myself to correct that after booting. Another issue I noticed was that after a reboot the status of the Autofan plugin is "stopped" (which is true..no running process)... If I go into the settings and select the pwm controller it says enabled...to actually get it running I have to selected "disable" then "enable" again and apply. Then the plugin / script actually starts working. Workaround for myself is a small userscript that checks if autofan is running (pgrep) and executes the "rc.autofan start" if not. Scheduled that every 5 minutes, so after latest 5 minutes the Autofan kicks in. Have yet to figure out why it is not started after a reboot. Any idea? Thats all for for now. Hope this helps in further development. Regards -MaNIaC-