If the script dumped things in the configured locations /storage/.config/argononed.conf will contain something like:
55=10
60=55
65=100
Left value is temp in ºC and right value is percentage of fan speed. So change values as you like and then reboot or restart the argononed systemd service, e.g. "systemctl restart argononed.service" to effect the change.
Then rejoice that fans in cases are totally unnecessary (and suck for HTPC devices) and put it back to normal so you can't hear it.
I just picked up one of these remote for my Coreelec box but i am unable to remap two of the buttons.
CE is 95% our codebase, but we don't bother to track what they leave out, or what special "fixes" are in-place that might break anything. So the best place to ask for support on their releases is their forum. Thanks.
Learn how to edit /storage/.kodi/userdata/sources.xml via SSH/nano and a spot of copy/past and then marvel at how simple and massively faster this is compared to manual browsing and the cumbersome task of adding username/password details using a remote control.
Two comments:
a) I don't see this behaviour myself with 4K HDR media. For reference my config.txt is here http://ix.io/28WU .. note I don't bother forcing the ability to output in 4k@60 because I don't posess any 4k media that runs at 4k60 apart from test files and the "up to 4k@30" support covers [email protected] which works fine, and like all the ARM devices I posess, the GUI runs best at 1080p anyway.
b) Development is focussed on the future GBM/V4L2 migration and moving away from the legacy 4.19 kernel and MMAL initial release compromise that's being used in LE 9.2 images, so even if there's a confirmed bug it's unlikely to be investigated and resolved.
Microsoft stopped Workgroup support in Windows 10. What is the current solution to the Windows name resolve issue? It doesn't seem to be working out of the box.
/storage/.config/hosts.conf .. which is applied to /etc/hosts on boot?
Browsing is gone and needs Kodi to think about adding support for ONVIF etc. but that will probably not happen until a more general refactoring of Kodi SMB support takes place. It's stinky fragile code so there's a long-running shortage of volunteers to touch it.
[ 12.803948@1] libphy: stmmac-0:00 - Link is Up - 1000/Full^ kernel boot to network 'up' is 12 seconds. For reasons unknown connman then reapplies the configurations which takes you to 14 seconds. If you delayed start until the network is up, Kodi takes a few more seconds. So 20 seconds sounds about right.
NB: Using an experimental mainline kernel image the time before Kodi starts is quicker but it's not a massive improvement. If you correlate events between http://ix.io/28WS and http://ix.io/28WR it shows boot is still about 12-14 seconds. The A53 CPUs in S905 devices are not particularly quick.
LE has no web browsers (for RPi). You can't get more secure than that 
Hi is there any more activity on this front
In a word, no.
There is no hibernate support in the RPi4 hardware (same for most ARM boards).
Once the KMS driver supports 10-bit output (almost there) HDR comes within reach; although most HDR media is HEVC and under GBM/V4L2 the HEVC support is still at a fairly experimental stage. RPi4 is an unusual SoC becuase H264 (the same IP from previous Pi generations which we've had working for a while) follows the stateful API while HEVC (new IP from another Broadcom chip, with all new code) follows the stateless API. Making it all work together (including the FFMpeg side) is uncharted territory. The first step is making something work. Then we have to make it work reliably. Then we have to get the code upstream (Royal 'we' .. the Pi Foundation folks). TL/DR; don't hold your breath just yet
If we turn our anti-spam defenses off to appease you (one user) we get overwhelmed fairly quickly by a ton of spam which pisses off all the moderators and staff of the project (many users) who support our userbase (several hundred thousand users). If we have to lose one user to keep everyone else happy .. sorry but we're not changing. This project is non-profit. This forum doesn't track anything. There are no advertising tools. 
"Support" in that context means you can boot the board. There's a ton more code required to get a functional media device!
Overall I am very happy to see a mix of the Pi Foundation staff, several core subcontractors they hired, and numerous names from the Pi ecosystem (including some of our own contributors) writing and upstreaming code to the kernel right now. The previous Pi architecture ended up being largely "out of tree" because when the first Pi launched in 2012 the folks who wrote the code were (in their own words) pretty ignorant about kernel things and the business priority was on shipping a working product. Over time their upstream awareness grew but the success of the Pi meant the task had become exponentially larger and still being a charity with a small staff the priority remained on shipping a working product. RPi0/1/2/3 are now super stable because the codebase has been iterated continuously and attentively over a period of seven years. RPi4 is being treated very differently. The benefits of being and business need to be "upstream" are very clearly understood now, and to continue the stratoshpheric success of Pi hardware the new shiny needs to mature a tad quicker than seven years. Lessons have been learned. Fortunately the success of the Pi means they're somewhat better funded this time around, so they aren't being shy about spending on good resources to get things done.
So .. to end my ramble. In the last few days some of the GBM/V4L2 work reached the point where we can package a "working" system on Linux 5.4 and we'll bump to Linux 5.5 soon. Proper public testing is still some way off as the transition from MMAL to GBM/V4L2 decoding means "one step forwards and two steps backwards" in the user experience due to the amount of new code involved. We'd like things to be closer to parity before we invite the masses to bug hunt. The greatest compliment will be a bunch of users whining about updating and not noticing any difference
Once Linux 5.6 lands in LE in a few months time we can switch devices to the in-kernel module and drop the wireguard-linux-compat package. Until then it's trivial to build as an out-of-tree package.
WireGuard support is now merged in LE master branch. I will wait on the connman bump before PR'ing to the 9.2 branch as well. It's in a functional state (it works for me) but I'm sure there are some lurking issues to find. Enjoy
There are HAT boards that exploit the ability to power an RPi via the GPIO pins. Basically you power the HAT board not the main board, and this means the IR sensor remains powered and able to recieve a power-on command when the main board is powered off. Have a look in some of the larger Pi reseller catalogues online and you'll find them.
The only time I've ever seen people trigger this sort of behaviour - they have been routing their traffic through Tor - which causes GeoIP to change with abnormal groundspeed and this (and other abnormal behaviours) triggers the captcha. It's part of our anti-spam defence and it will not be turned off.
/storage/.config/autostart.sh is run at userspace boot, so (sleep 10 && background the commands)& that you want to run and put them there, or create a systemd .service file in /storage/.config/system.d/routes.service with the commands you want, with dependencies on connman so the network is up before the commands are applied. LE has non-standard packaging - you cannot apply persistent network config, but there are ways to persistently (re)apply config.
First thing to do is create an image (dump) of the SD card .. if this is possible. Then you put the SD card somewhere safe and concentrate on trying to recover data from the image. Linux has numerous data recovery utilities that can look for raw data on the card/image. If you cannot get anything from the card .. the data is gone. SD cards a pretty reliable these days, but everything has a lifespan, and there are only two kinds of computer user: a) people who back up their stuff all the time, and b) people who haven't lost all their data yet.
