NickS

Hi jotapesse, yes same for me ... but on closer inspection ... the flashing of the LAN activity light no longer seems to be tied to real network activity! 1/ It flashes a lot less than it used to do. 2/ If I download a large movie file from the Helios64 to my PC I occasionally see a brief flash, but not the sustained activity that I'd expect from a download that takes several minutes. 3/ Inspecting my network router, I can see constant low level activity on the Helios64 ip address (I only have one ethernet cable attached to the Helios64) but don't see any flashing LED. So in conclusion ... its still not working properly!

Hello liberodark, I'm not sure you have the same problem as me - although it is possible the two problems are related. My system boots fine and my eth0 adaptor and network are all running OK - for me its just the activity indicator on the front panel that no longer works. It sounds like your network is not working at all ... Nick

Hello again Groetjes, thanks for your reply. Yes "echo 'activity' | sudo tee '/sys/class/leds/helios64:blue:net/trigger'" has an effect. The LED is now flashing blue on and off. I presume "activity" is the module designed for the "System Activity LED" and that "netdev" was supposed to do a similar job for the the "LAN Activity LED" - but no longer does. Regards ... Nick

Hello again Groetjes. There is no difference after the echo command - the LED remains off. I rebooted - just in case - still no difference. Regards ... Nick

Hi Groetjes, thanks for the interest. Here's the info you asked for... root@Helios64:~# echo 'netdev' | sudo tee '/sys/class/leds/helios64:blue:net/trigger' netdev root@Helios64:~# Regards ... Nick

Hi I'm talking about the BLUE "LAN Activity LED" on the front panel. On release of the first batch of Helios64 this "LAN Activity LED" was always inactive as it wasn't yet supported by the software. At some point during development (I can't remember when) there was an update which enabled support and it worked fine until recently. Kind regards ... Nick

Helios64 network activity light no longer flashes (always off). I have one ethernet cable attached to eth0 and enabled. Otherwise eth0 is working fine Helios64 is rebooted each 24 hours. If I echo "1" to /sys/class/leds/helios64:blue:net/brightness then LED lights up OK. Contents of /sys/class/leds/helios64:blue:net/trigger [none] usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on panic mmc1 mmc2 netdev stmmac-0:00:link stmmac-0:00:1Gbps stmmac-0:00:100Mbps stmmac-0:00:10Mbps rc-feedback tcpm-source-psy-4-0022-online gpio-charger-online rfkill-any rfkill-none phy0rx phy0tx phy0assoc phy0radio rfkill0 System level Linux Helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux PRETTY_NAME="Armbian 21.08.2 Buster" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

Stable System: Absolutely I'm running with all latest maintenance & OMV5. Linux 5.10.21-rockchip64, OMV 5.6.2-1(Usul) ---- but I'm keeping things very simple... NO RAID 4 x HDD ALL THE SAME NO ZFS BOOT FROM SD AUTO SHUTDOWN & RESTART EACH 24 hours -- until I get to the apps 21 Docker containers running various apps & services. I've had one docker image fail to come up on a couple of occasions. So ... I'm a very happy customer. My Data resilience doesn't come from RAID (which I really don't like 'cos 8TB disks take forever to rebuild). I just backup critical data to my old trusty Helios4!

Hi gprovost, Yes I happened to find RTC in the doc yesterday! I'm still using auto power on in case of power failure. But, as you kindly suggest, I'm now using RTC - 2 tasks in OpenMediaVault5 job scheduling... 1/ sudo rtcwake -m disable (each reboot to reset any outstanding wake timers) 2/ sudo rtcwake -m off --date '+ 6 hour 15 minutes 0 seconds' (each morning at 01:00 to shutdown and set wake timer for 07:15) It worked fine this morning!

OK Thanks ebin-dev For others who are as dumb as me you need to edit "/lib/systemd/system-shutdown/disable_auto_poweron" and change line ... "echo 0 > /sys/class/gpio/gpio153/value" to "echo 1 > /sys/class/gpio/gpio153/value" and it works!!!

My NAS do very little overnight so my NAS4 shuts down in the evening and shortly afterwards a physical time switch cuts the power - reinstating power in the morning at which time the NAS4 automatically reboots. I want to do the same with the NAS64 - but even though I've read this (https://wiki.kobol.io/helios64/auto_poweron/) I'm not sure how to go about it. I can't understand if it only works if the UPS has died, or if I have to run a script before shutdown or both. Could you please clarify? Thx ... Nick

Just happened to be in my office when I heard a sharp crack from one of my 2 Helios4 servers which were both up and running at the time. Noticed that the LED display on one had frozen and could not get that server to respond. Recycled the power on it and although it came up with LED shining, on investigation no power to HDDs or fans. Suprising it booted at all, but it did! Swapped power supplies and issue moved with the PSU so looks like I have a deadish PSU. Pulled it apart and can see 2 of the 1000mf capacitors have blown. Would have replaced them but the massive heat sink is in the way and is soldered to too many components to bother. I'll buy a new one. Lesson 1: Immediately suspected the power supply as other users have been complaining about them nearing end-of-life - so thanks for those users writing on this forum. Lesson 2: These PSUs can partially fail and may at first appear to be OK. Lesson 3: My data base was backed up on the surviving server:} Good job because apart from that being corrupted everything else is OK. Restored db and server is back up - but I can only run one at a time until I source another PSU. Kind regards ... Nick

Unfortunately no. You'll want to transcode ahead of time and use direct play if you want to use helios as plex server I do, and although I try to rerender content manually, occasionally I just let the software carry the load. I use serviio as my DLNA server on the Helios4. It has the capacity to set up different render profiles for a plethora of target devices so you can present full quality and bitrate to say a TV but less so for a tablet. For remote viewing you'll have to pay the small subscription, but there is a 30day full free test. I'm not sure the Helios4 has the horespower to do more than one render at a time. A bit like someone flushing the toilet when their partner is in the shower! Installation instructions attached. serviio.txt

The following patch makes fans revert to slow on shutdown rather than top speed! ================================================================================ --- /usr/sbin/fancontrol 2018-02-17 13:54:50.065478090 +0800 +++ /usr/sbin/fancontrol 2018-02-17 13:58:56.910831481 +0800 @@ -334,7 +334,7 @@ # No enable file? Just set to max if [ ! -f $ENABLE ] then - echo $MAX > $1 + echo $MINPWM > $1 return 0 fi @@ -433,9 +433,9 @@ fi # If fanspeed-sensor output shall be used, do it + min_fanval=100000 if [[ -n ${fan} ]] then - min_fanval=100000 fanval= # A given PWM output can control several fans for one_fan in $(echo $fan | sed -e 's/+/ /')

Hi sirleon, I'm running OMV4 in my deployment, and a recent set of updates broke "psutil.disk_io_counters()". If you are using this routine in your OLED code to fetch disk information then this may be your problem. Anyway you should SSH into your NAS and run the OLED code directly from the SSH terminal and let us see all the nice error messages it throws up :}