Dynamix - V6 Plugins


Recommended Posts

I've been messing around with the Day Night plugin a little bit for alternate ways of getting the sun set/rise information without using one of the existing service APIs..  well I didn't quite succeed in not needing an API key for something..

 

But I did manage to add another service that seems to work ok with the changes I played with...

 

The site is zipcodeapi.com, you still need to register for an API key but it was very much easier than using any of the existing services offered (Google, MapQuest, Bing)..  Unfortunately for the world-wide use of Unraid, this site is for the USA only as it only requires the zip code to work.  Anyone that tries this seems to only need the Application Key and not a javascript website key (you'll see what I'm talking about if you register on the site).

 

To implement was pretty easy.. these are the changes I made to the plugin files.. I didn't handle all the form entries to make it only show the zip code field, but the zip code is all that's needed.

 

I'll just show my additions to the functions, any other code stays as is.

 

\usr\local\emhttp\plugins\dynamix.day.night\DayNightSettings.page


function prepareAPI(form) {
    case 'zipcodeapi' : form.apikey.value = form.zipcodeapi.value; break;

 


function changeAPI(api) {
    case 'zipcodeapi'  : $('div.google').hide(); $('div.bing').hide(); $('div.quest').hide(); $('div.zipcodeapi').show(); break;

 

Below the ending </div> tag under _(Postal code)_:


<div markdown="1" class="zipcodeapi" style="display:none">
_(Postal code)_:
: <input type="text" name="zipcode" class="narrow" maxlength="9" value="<?=$my['zipcode']?>">

</div>

 


_(Geocoding service)_:
  <?=mk_option($my['geocode'], 'zipcodeapi', _('zipcodeapi'))?>

 

Below the ending </div> tag under (MapQuest API key)_:


<div markdown="1" class="zipcodeapi" style="display:none">
_(zipcodeapi API key)_:
: <input type="text" name="zipcodeapi" maxlength="99" value="<?=$my['zipcodeapi']??$my['apikey']?>"> _(See)_ [_(this site)_](https://www.zipcodeapi.com) _(to obtain a ZipCodeAPI API key)_

</div>

 

In \usr\local\emhttp\plugins\dynamix.day.night\include\update.theme.php

Added below the quest switch function


  case 'zipcodeapi':
    $address = combine(',',$_POST['zipcode']);
    $loc = geocode("https://www.zipcodeapi.com/rest/{$_POST['apikey']}/info.json/$address/degrees");
    $lat = $loc['lat'] ?? false;
    $lng = $loc['lng'] ?? false;
    $keys['address'] = $loc['results'][0]['providedLocation']['location'] ?? '';
    break;   

 

Like I said, it seems to work ok.

 

I also came across a site that with a little bit of knowledge and work you could make this plugin work without any need for an api key.

 

A call to the free API at https://sunrise-sunset.org/api with only the latitude and longitude would get you the UTC time for sunrise and sunset, but you 1) have to have a way of getting the lat/long without an API key, and 2) convert the returned UTC time to user's local time in order to get the correct time.

 

 

Also came across some stuff that might be able to be used to take this plugin completely offline without the need for any other services, but might be more work/trouble than it's worth...

https://www.esrl.noaa.gov/gmd/grad/solcalc/main.js

and

https://github.com/mourner/suncalc

 

 

Well everyone, have fun with this bit of useless information :P

 

 

Link to comment
On 6/29/2020 at 5:27 PM, nickp85 said:

Having an issue with cache directories plugin.  I configured it mostly as default however I am getting every 5-10 seconds a CPU spike on one core by the "sh" process.  If I turn off cache directories it goes away.  I'm only caching two shares, my files and multimedia, about 11 TB worth of data.  I also tried to limit the adaptive depth to 10 or 15 but no good.

 

How can I get this process not to spike my CPU consistently?  I'm not using the /mnt/user option either.

Curious about this as well, My CPU normally sits around ~3-5% but with the folder cache enabled it spends almost half the time around ~20-30% usage.

 

Not using the /user option and also mostly default settings.

 

Seems really excessive when it should not be doing anything once the folders are cached.

Edited by TexasUnraid
Link to comment
5 hours ago, TexasUnraid said:

Seems really excessive when it should not be doing anything once the folders are cached.

To keep folders cached by Linux, it requires periodic updates, read: full scans of those folders every so many seconds.

When you have cached folders with many levels and/or files, it will make your system more busy and of course consumes your RAM memory.

 

Link to comment
8 hours ago, bonienl said:

To keep folders cached by Linux, it requires periodic updates, read: full scans of those folders every so many seconds.

When you have cached folders with many levels and/or files, it will make your system more busy and of course consumes your RAM memory.

 

I am guessing you are saying that it is scanning the cached version of those folders since the drives are spun down and it can't read the actual folders?

 

How fast does linux drop the cache? Is there a way to extend it? I am not worried about memory usage since I have 32gb and only use like 8gb unless running VM's.

 

Seems like it would be able to go more then ~10-20 seconds between scans?

Link to comment

Been playing around with the settings, I found that reducing the cache depth down to 5 and the cache pressure to 1 drastically reduced the CPU usage. Now it just spikes up to ~7-10% usage every few seconds instead of stilling at 20-30% for 50-60% of the time.

 

Just need to figure out the ideal depth it seems.

 

If I am going more then 5-6 folders deep on a drive it will most likely need to be spun up anyways I figure.

 

Interestingly, excluding SSD shares that I know have a lot of folders in them does not seem to reduce the CPU usage much if at all.

Edited by TexasUnraid
Link to comment
On 6/21/2020 at 1:28 PM, bonienl said:
On 6/21/2020 at 12:58 PM, MothyTim said:

After last nights update AutoFan is completly broken

 

Jul 2 22:24:16 Raptor root: plugin: running: anonymous
Jul 2 22:27:06 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install https://raw.githubusercontent.com/bergware/dynamix/a088b81081160482030019ccd61790428bbb805c/unRAIDv6/dynamix.system.autofan.plg
Jul 2 22:27:13 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin remove dynamix.system.autofan.plg
Jul 2 22:27:13 Raptor root: plugin: running: anonymous
Jul 2 22:27:18 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install https://raw.githubusercontent.com/bergware/dynamix/a088b81081160482030019ccd61790428bbb805c/unRAIDv6/dynamix.system.autofan.plg
Jul 2 22:27:18 Raptor root: plugin: running: anonymous
Jul 2 22:27:18 Raptor root: plugin: creating: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - downloading from URL https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.system.autofan.txz
Jul 2 22:27:18 Raptor root: plugin: checking: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - MD5
Jul 2 22:27:38 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install https://raw.githubusercontent.com/bergware/dynamix/a088b81081160482030019ccd61790428bbb805c/unRAIDv6/dynamix.system.autofan.plg
Jul 2 22:27:38 Raptor root: plugin: running: anonymous
Jul 2 22:27:38 Raptor root: plugin: creating: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - downloading from URL https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.system.autofan.txz
Jul 2 22:27:39 Raptor root: plugin: checking: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - MD5
Jul 2 22:29:26 Raptor login[15500]: ROOT LOGIN on '/dev/pts/0'
Jul 2 22:30:48 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install /boot/config/plugins/dynamix.system.autofan.plg
Jul 2 22:30:48 Raptor root: plugin: running: anonymous
Jul 2 22:30:48 Raptor root: plugin: creating: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - downloading from URL https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.system.autofan.txz
Jul 2 22:30:48 Raptor root: plugin: checking: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - MD5
Jul 2 22:32:35 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin install /boot/config/plugins/dynamix.system.autofan.plg
Jul 2 22:32:35 Raptor root: plugin: running: anonymous
Jul 2 22:32:35 Raptor root: plugin: creating: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - downloading from URL https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.system.autofan.txz
Jul 2 22:32:35 Raptor root: plugin: checking: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - MD5
Jul 2 22:34:02 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin_rm /boot/config/plugins-error/dynamix.system.autofan.plg
Jul 2 22:34:22 Raptor emhttpd: cmd: /usr/local/emhttp/plugins/community.applications/scripts/pluginInstall.sh install https://raw.github.com/bergware/dynamix/master/unRAIDv6/dynamix.system.autofan.plg
Jul 2 22:34:23 Raptor root: plugin: running: anonymous
Jul 2 22:34:23 Raptor root: plugin: creating: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - downloading from URL https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.system.autofan.txz
Jul 2 22:34:23 Raptor root: plugin: checking: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz - MD5
Jul 2 22:34:23 Raptor root: plugin: running: /boot/config/plugins/dynamix.system.autofan/dynamix.system.autofan.txz
Jul 2 22:34:23 Raptor root: plugin: creating: /tmp/start_service - from INLINE content
Jul 2 22:34:23 Raptor root: plugin: setting: /tmp/start_service - mode to 0770
Jul 2 22:34:23 Raptor root: plugin: running: anonymous
Jul 2 22:34:54 Raptor ool www[16948]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:35:02 Raptor ool www[16948]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:35:22 Raptor ool www[16061]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:35:28 Raptor ool www[16948]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:35:28 Raptor autofan: autofan process ID 17353 started, To terminate it, type: autofan -q -c /sys/class/hwmon/hwmon2/pwm1 -f /sys/class/hwmon/hwmon2/fan1_input
Jul 2 22:35:33 Raptor autofan: Highest disk temp is 31C, adjusting fan speed from: FULL (100% @ 0rpm) to: OFF (0% @ 0rpm)
Jul 2 22:35:41 Raptor ool www[17099]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:35:54 Raptor ool www[17289]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:36:41 Raptor ool www[17099]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:37:01 Raptor ool www[17289]: /usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan 'start'
Jul 2 22:37:01 Raptor autofan: autofan process ID 18017 started, To terminate it, type: autofan -q -c /sys/devices/platform/nct6775.656/hwmon/hwmon2/pwm2 -f /sys/devices/platform/nct6775.656/hwmon/hwmon2/fan4_input
Jul 2 22:37:01 Raptor autofan: autofan excluding drives sdd,sde,sdf,sdi,sdj,sdk,sdl,sdg,sdh from max temp calculations
Jul 2 22:37:06 Raptor autofan: Highest disk temp is 0C, adjusting fan speed from: FULL (100% @ 1400rpm) to: OFF (0% @ 508rpm)

Error log doesn't seem to appear in the folder either 👀

 

root@Raptor:/boot/config/plugins-error# ls -lah
total 16K
drwx------ 2 root root 8.0K Jul  2 22:34 ./
drwx------ 8 root root 8.0K Jul  2 22:30 ../
root@Raptor:/boot/config/plugins-error# 

Can't get autofan to run against PWM 2 - it tries to save but never completes, defaults to PWM 1 and setting the plugin to "Disabled" doesn't disable it haha!

 

Let me know if I can do anything to help out!

- I tried to install an old plugin version from GitHub but it doesn't think the MD5 matches but I know the issue didn't exist in older versions of the plugin

Link to comment
2 hours ago, nexusmaniac said:

 

 Can't get autofan to run against PWM 2 - it tries to save but never completes, defaults to PWM 1 and setting the plugin to "Disabled" doesn't disable it haha!

 

I was playing with autofan only last week, and thought, like you, that it was erroneously reverting to PWM 1 everytime I tried to configure PWM 2.  I discovered that autofan is actually more functional than I first thought, but that isn't clear from the user interface.  It seems that autofan discovers all the PWM controllers and allows you to enable/disable/configure each of them independently.  It actually keeps separate .cfg files for each PWM controller.  However, it still doesn't appear to get everything correct and the integration with System Temperature is a little suspect.

I'm currently on 2020.06.21 version - I'm not sure which update you're referring to.

Link to comment

Two bugs with auto fan it have cropped up since updating to the latest version and unraid 6.9 beta:
1) It does not respect min PWM, and will shut fans down when below the temp range. This is unexpected behavior and should be either toggleable, or at least clearly worded as many servers use the same fans for general system airflow.

2) It seems to incorrectly detect highest disk temp. 

As an example, logs:

Jul 2 20:40:56 jibril autofan: Highest disk temp is 36C, adjusting fan speed from: OFF (0% @ 0rpm) to: 136 (53% @ 0rpm)
Jul 2 20:42:03 jibril autofan: Highest disk temp is 35C, adjusting fan speed from: 136 (53% @ 4021rpm) to: OFF (0% @ 3448rpm)
Jul 2 20:45:13 jibril autofan: Highest disk temp is 36C, adjusting fan speed from: OFF (0% @ 0rpm) to: 136 (53% @ 0rpm)
Jul 2 20:46:20 jibril autofan: Highest disk temp is 35C, adjusting fan speed from: 136 (53% @ 4000rpm) to: OFF (0% @ 3579rpm)
Jul 2 20:49:30 jibril autofan: Highest disk temp is 36C, adjusting fan speed from: OFF (0% @ 0rpm) to: 136 (53% @ 0rpm)
Jul 2 20:50:37 jibril autofan: Highest disk temp is 35C, adjusting fan speed from: 136 (53% @ 4043rpm) to: OFF (0% @ 3448rpm)
Jul 2 20:52:45 jibril autofan: Highest disk temp is 36C, adjusting fan speed from: OFF (0% @ 0rpm) to: 136 (53% @ 0rpm)
Jul 2 20:53:52 jibril autofan: Highest disk temp is 35C, adjusting fan speed from: 136 (53% @ 4043rpm) to: OFF (0% @

Meanwhile I'm getting high temp alarms on two drives, coldest spinning is 44C. 

 

Of possibly interesting note: Disk 1 was spun down at the time so unraid didn't show its temp, but I noticed later the logs do seem to roughly match that drive. It's also the only non-SAS drive in my array.

 

Edited by Spitko
Link to comment
1 hour ago, Spitko said:

Two bugs with auto fan it have cropped up since updating to the latest version and unraid 6.9 beta:
1) It does not respect min PWM, and will shut fans down when below the temp range. This is unexpected behavior and should be either toggleable, or at least clearly worded as many servers use the same fans for general system airflow.

2) It seems to incorrectly detect highest disk temp. 

 

No 1 I've noticed recently, but not a problem for me - my PWMs don't shutdown, but run about 30% when 0 is sent.

No 2 doesn't seem to be happening here - my log shows autofan switching between 39C and 40C, while the Unraid main tab is showing that the highest temp is currently 40C.

Link to comment
  • 2 weeks later...
On 6/23/2020 at 1:08 PM, GFRoSTY said:

I

 

I can second this find.

I'm playing with a HP NL54 microserver.

After installing the plugin it detects the correct sensors.

Aufnahme2.png.66dffb3b54ba3c06c87285bbc62f54ab.png

 

Assignment of sensors

Aufnahme3.png.c928d8fde46e324edab382a9573bb01c.png

 

Pressing "APPLY"

Aufnahme5.png.f43bfb06c19f7aabec4db849be4aea80.png

Of course, no sensor data is displayed.

 

After deleting /etc/sensors.d/sensors.conf I can repeat the procedure. If the file is not deleted or modified like below, no chance to

get the selection back.

 

Initial sensors.conf

root@Tower:~# cat /etc/sensors.d/sensors.conf
# sensors
chip "k10temp-pci-00c3"
label "temp1" "CPU Temp"
chip "w83795adg-i2c-1-2f"
label "temp2" "MB Temp"
chip "w83795adg-i2c-1-2f"
label "fan1" "Array Fan"
root@Tower:/etc/sensors.d# sensors
Error: File /etc/sensors.d/sensors.conf, line 4: Undeclared bus id referenced
Error: File /etc/sensors.d/sensors.conf, line 6: Undeclared bus id referenced
sensors_init: Can't parse bus name

 

Deleted the sensors.conf and rescan. Sensors were back for selection in the GUI.

Note, the K10 sensor disappeared...

Pressed APPLY again and they were gone.

I change the sensors.conf like this

root@Tower:/etc/sensors.d# cat /etc/sensors.d/sensors.conf
# sensors
chip "w83795adg-i2c-12f"
label "temp1" "CPU Temp"
chip "w83795adg-i2c-12f"
label "temp2" "MB Temp"
chip "w83795adg-i2c-12f"
label "fan1" "Array Fan"

 

root@Tower:/etc/sensors.d# sensors
Error: File /etc/sensors.d/sensors.conf, line 2: Parse error in chip name
Error: File /etc/sensors.d/sensors.conf, line 4: Parse error in chip name
Error: File /etc/sensors.d/sensors.conf, line 6: Parse error in chip name

But the sensors reapear in the GUI.

Of course there is no further benefit in having them back for selection, as long as they can't be saved and the temps are not displayed

as intended.

 

@bonienl Please let me know how I can contribute further to help debugging this issue.

 

I also noticed this little spelling error in the mouseover.

Aufnahme7.png.be27734ff37636b0a875089d733bc784.png

Edited by Fireball3
Link to comment

FWIW

 

I edited the go file and added "modprobe nct6775 force_id=0xd120" entry that was recommended in earlier thread and reboot and it worked.

 

/boot/config/go

 

root@Tower:/boot/config# cat go
#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &
modprobe nct6775 force_id=0xd120

 

I'm using MSI X570 Tomahawk

Link to comment
49 minutes ago, acosmichippo said:

I have a dumb question.  Trying to look up the help on the Folder Caching for cache pressure, but... where is the help?

 

Thanks!

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Quote

 

vfs_cache_pressure

------------------

This percentage value controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. Increasing vfs_cache_pressure significantly beyond 100 may have negative performance impact. Reclaim code needs to take various locks to find freeable directory and inode objects. With vfs_cache_pressure=1000, it will look for ten times more freeable objects than there are.

 

 

Link to comment
On 9/30/2018 at 10:45 AM, bonienl said:

# Generated array status check schedule: 20 0 * * * /usr/local/emhttp/plugins/dynamix/scripts/statuscheck &> /dev/null

Not sure if i'm in the right topic here. I've been search for hours to no avail. How can you change the time of these? i have notifications via pushover and i dont want it going off at these times, i simply want to change them to more reasonable times. I've tried chaning both Dynamix config in boot/config/plugins/dynamix and the status-check.cron files, but it either doesn't work, or it reverts back after a reboot. I've thought of disabling them all together and using user scripts to run the checks, but then i wont get the pushover notifications

Edited by MitchElwell
Link to comment
On 7/13/2020 at 2:13 PM, Fireball3 said:

I can second this find....

Thirding this, my sensors suddenly all vanished (Beta 25 if that helps). Manually editing sensors.conf and removing an extra dash from the jc42 sensor fixed this for me after my sensors all dropped off the face of the earth suddenly.

 

Upon further sleuthing, this doesn't ACTUALLY fix the issue though, the sensors command whines and the labels don't work properly if you have overlaps (ie, "temp1" isn't properly pinned to jc42). It seems the "correct" fix is to add a bus statement before the chip, eg

chip "k10temp-pci-00c3"
label "temp2" "CPU Temp"
bus "i2c-0" "SMBus adapter"
chip "jc42-i2c-0-19"
label "temp1" "MB Temp"

fixes the error, though I'm still having trouble getting the label command to work properly, time to hit the man pages I guess. HOWEVER, it's worth noting that jc42 are smbus memory sensors, so this has been mostly a goose chase; mobo temp can't yet be read as we're still missing a driver in unraid for the ITE IT8665E

 

That said, selecting jc42 forever breaks the plugin since it won't remove the line from sensors.conf, and one selected it writes a bad line that breaks the sensors command. The current fix is to remove the line manually from sensors.conf, the plugin should either handle smbus sensors properly or, as a hotfix, just blacklist jc42 and handle the failure mode better.

Edited by Spitko
Link to comment

I'm trying to get Auto Fan Control working but I receive the following "PWM Fan" response when when Detect is selected for any of the PWM controllers in the drop down list.

 

 

<br /><b>Warning</b>:  file_put_contents(): Only 0 of 1 bytes written, possibly out of free disk space in <b>/usr/local/emhttp/plugins/dynamix.system.autofan/include/SystemFan.php</b> on line <b>42</b>

 

<br /><br /><b>Warning</b>:  file_put_contents(): Only 0 of 3 bytes written, possibly out of free disk space in <b>/usr/local/emhttp/plugins/dynamix.system.autofan/include/SystemFan.php</b> on line <b>43</b>

 

<br /><br /><b>Warning</b>:  file_put_contents(): Only 0 of 3 bytes written, possibly out of free disk space in <b>/usr/local/emhttp/plugins/dynamix.system.autofan/include/SystemFan.php</b> on line <b>46</b>

 

<br /><br /><b>Warning</b>:  file_put_contents(): Only 0 of 3 bytes written, possibly out of free disk space in <b>/usr/local/emhttp/plugins/dynamix.system.autofan/include/SystemFan.php</b> on line <b>49</b><br />

 

Unraid 6.8.3

Auto Fan Control is current 2020.06.21 

 

df -h gives:

Filesystem      Size  Used Avail Use% Mounted on
rootfs          2.9G  920M  2.0G  32% /
tmpfs            32M  444K   32M   2% /run
devtmpfs        2.9G     0  2.9G   0% /dev
tmpfs           3.0G  8.0K  3.0G   1% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  196K  128M   1% /var/log
/dev/sda1       3.8G  777M  3.0G  21% /boot
/dev/loop0      9.2M  9.2M     0 100% /lib/modules
/dev/loop1      7.3M  7.3M     0 100% /lib/firmware

 

 

Edited by MartinQ
Link to comment
On 7/28/2020 at 2:12 PM, Spitko said:

Thirding this, my sensors suddenly all vanished (Beta 25 if that helps). Manually editing sensors.conf and removing an extra dash from the jc42 sensor fixed this for me after my sensors all dropped off the face of the earth suddenly.

 

Upon further sleuthing, this doesn't ACTUALLY fix the issue though, the sensors command whines and the labels don't work properly if you have overlaps (ie, "temp1" isn't properly pinned to jc42). It seems the "correct" fix is to add a bus statement before the chip, eg


chip "k10temp-pci-00c3"
label "temp2" "CPU Temp"
bus "i2c-0" "SMBus adapter"
chip "jc42-i2c-0-19"
label "temp1" "MB Temp"

fixes the error, though I'm still having trouble getting the label command to work properly, time to hit the man pages I guess. HOWEVER, it's worth noting that jc42 are smbus memory sensors, so this has been mostly a goose chase; mobo temp can't yet be read as we're still missing a driver in unraid for the ITE IT8665E

 

That said, selecting jc42 forever breaks the plugin since it won't remove the line from sensors.conf, and one selected it writes a bad line that breaks the sensors command. The current fix is to remove the line manually from sensors.conf, the plugin should either handle smbus sensors properly or, as a hotfix, just blacklist jc42 and handle the failure mode better.

Im 4thing this issue....When I first load in the plugin, it detects everything.  Then when I hit apply, all of my sensors and fan disappear.  Cant get it back until I completely wipe it out.  Running beta 25.

Link to comment

Will cache Dir's be updated to work with 6.9?

 

It does not detect folders to exclude when they are on one of the new cache pools with 6.9 it seems, these are on a secondary cache pool:

Jul 31 08:50:39 NAS cache_dirs: ERROR: excluded directory 'appdata' does not exist.
Jul 31 08:50:39 NAS cache_dirs: ERROR: excluded directory 'domains' does not exist.
Jul 31 08:50:39 NAS cache_dirs: ERROR: excluded directory 'isos' does not exist.
Jul 31 08:50:39 NAS cache_dirs: ERROR: excluded directory 'lancache' does not exist.
Jul 31 08:50:39 NAS cache_dirs: ERROR: excluded directory 'system' does not exist.

 

Edited by TexasUnraid
Link to comment
31 minutes ago, bonienl said:

I made an update which fixes the multi pool issue. Please try.

Just tested it, yep, seems to of fixed the multiple cache pools.

 

Although I had a manual exclusion -e My_Share in the User defined options. This was to exclude a UD mounted network share. This now gives an error.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.