What am I missing?
/boot/config.txt parameters are for when the system is running, not when it is powered off.
If there is an option for it, it would most likely be set via the rpi-eeprom-config
This is where is reduced my standby power by 140x from 1.4w to 0.01w:
Reducing Raspberry Pi 5's power consumption by 140x | Jeff Geerling
I have not found it, but if you do share it here 
chewitt I saw that Armbian is starting support for the R76S. So I'm gathering info/files on the device before it gets here. Hopefully by the end of next week. I figured I could maybe franken-boot an RK3576 image. Which one do you recommend:
2025-09-09 03:01:38: Saving config: write /storage/.kodi/userdata/addon_data/service.system.syncthing/.syncthing.tmp.793318938: no space left on device
Well that kind of says it all doesn't it ? Syncthing uses temp files wearing out your emmc on top of your free space issue.
Best thing to do is to relocate tempfiles if the addon has that option.
If 'not' you can:
# Move addon_data to hdd
mv /storage/.kodi/userdata/addon_data/service.system.syncthing /path/to/hdd/service.system.syncthing
# Create a soft link to the new location
ln -s /path/to/hdd/service.system.syncthing /storage/.kodi/userdata/addon_data/service.system.syncthing
# Set the immutable attribute to prevent accidental deletion
chattr +i /storage/.kodi/userdata/addon_data/service.system.syncthingTo undo it:
# Remove the immutable attribute that prevents deletion
chattr -i /storage/.kodi/userdata/addon_data/service.system.syncthing
# Remove the soft link to the new location
rm /storage/.kodi/userdata/addon_data/service.system.syncthing
# Move addon_data back to emmc
mv /path/to/hdd/service.system.syncthing /storage/.kodi/userdata/addon_data/service.system.syncthingGood luck 
PS: dont forget to backup LE, before doing this, just in case.
That would be today then 
Most Unix/Linux users have no need for an installer, its just so basic.
So if you see a black screen, SSH in and check the kodi.log to see whether that's happening (or not) before forcing an update.
Yeah, I think I jumped the gun there. However there was no splash and I've seen the db migration take place over the years and afaict that should happen during the first boot of a newer version. I upgraded a few days earlier and it worked just fine, then all of a sudden hung on the black screen one day.
I checked that its not the hardware nor the sdcard . I use them industrial cards because they are speedy for reading and writing, they're cheap and the occasional restore is really really fast (for micro sdcards that is).
Other than a dirty write I have no clue what could have caused it.
It seems that Wifi isn't connecting, so when it boots it goes into a loop of not connecting to the video database, and then back, and never boots.
I had a similar issue where the rpi5 would boot (image:20250828 12.2) and nothing would happen, screen stayed black, but i could still ssh into it. (and this was after a couple of days working just fine). So I forced an update (same image) and the problem disappeared. Until I read your post I thought it was a one off. So I figured to at least mention it here just in case.
A while ago lightning hit near my house and caused a short blip
Contact insurance and check your other house equipment in the mean while. I had something like that years ago and I was covered.
Except, I think this may have affected something on the Pi5 but it's ... odd and I can't rule out a configuration problem
720, that's and odd problem.
To rule out any issue, start replacing components one by one. In your case I would create a new LE sdcard and test the basics. If the problem remains move on to the next like cables and such. Then finally try a different TV just to rule things out.
If all remains the same you most likely have a board issue. Take it out and try to look for any burn marks. Sniff it, sometimes it smells but you cant see any damage. Most likely place would be near any connectors where cables go into the board.
Good luck.
The most interesting the image LibreELEC-RK3588.aarch64-12.90.1-rock-5c.img.gz does. But during loading there is an error about mount disk uuid=5899aaae-1fbd-4452-8807-236cf98c8c98.
The DTB is different between those 2 boards. Most likely storage isn't (or not 100%) recognized and therefore fails to boot. My 2cts.
You could try to franken-boot it. I did something like that here.
No idea, I have no RPi cases kicking around at the moment (other than RPi5 cases which definitely aren't the same).
I looked but couldn't find a good case to match the board which could be a reason why it has such a competitive price. Its the R76S for me, once I have convinced myself to part with my money that is 
EGL rendering is always a workaround not a solution, as it's not as efficient as DRMPRIME rendering.
Agreed, I read up on Patch v2 that enables x264/x265 decoding and there are still some small issues. WIP 
I've been running tests on an RK3576 Rock-4D board. The kernel codebase is still maturing in places but I think this will be a nice sweet-spot for LE use. The boards are less-featured than RK3588, which makes the boards cheaper, but the peripherals that have been omitted are all things that LE has no use for, while the media capabilites are essentially the same.
I have my eye on the NanoPi R76S because it could possibly free up an R6C which you so kindly added exp. support for 
Looking at it 
its very small (2.3"x2.3"), so as a router its great, but I wonder if it has any LE potential compared to the Rock-4D.
edit:
I could not find a case for the Rock-4D, does it fit a PI-case by any chance?
So the steps I had to take:
I owned a T620 (the thin one), writing the x86_64 image with dd was always sufficient for me for it to boot right of the bat.
$ wget https://releases.libreelec.tv/LibreELEC-Generic-legacy.x86_64-12.2.0.img.gz
Saving to: ‘LibreELEC-Generic-legacy.x86_64-12.2.0.img.gz’
$ zcat LibreELEC-Generic-legacy.x86_64-12.2.0.img.gz | tee >(dd bs=10M oflag=sync of=/dev/sdX) | sha256sum
0+105191 records in
0+105191 records out
7b7090c3b54c4d177f441c557102c26dde828176a09be8b177f1606248433f82 -
1112539136 bytes (1,1 GB, 1,0 GiB) copied, 61,96949 s, 16 MB/s
$ pv -s 1112539136 -S /dev/sdX | sha256sum
7b7090c3b54c4d177f441c557102c26dde828176a09be8b177f1606248433f82 -I do remember factory resetting the T620, by setting a jumper back and forth.
EGL rendering is always a workaround not a solution, as it's not as efficient as DRMPRIME rendering. Interesting to know that it has impact though. DRMPRIME is the correct configuration to be using (in the long-term).
Yeah, I figured as much and it was only noticeable on my TV.
Images are updated with u-boot 2025.10-rc3 to pull in Kwiboo changes for RK3576 boards. In theory no changes for older boards but you never know.
Since you mentioned the RK3576 boards, I was reading this: https://forum.openwrt.org/t/friendlyelec-nanopi-r76s/236429
From a performance and cost standpoint it is less powerful than the R6C/R6S but more powerful than the R5C and R3S. DTS files for the Rockchip RK3576 are already in the mainline kernel so it shouldn't be difficult to get OpenWRT running on it either.
Just curious if this also applies to LibreElec ?
Yes!, the "Turn Off" screensaver worked like a charm.
Weird that is isn't part of the CEC package.
Thanks
Elicity I've picked the patches for R6C. If you update using the RK3588 .tar file in my test share HDMI audio should work now?
YES it does!
Yahoo, it works like a charm. OMG this amazing, I've played around with it for a couple of hours now. Watched an entire movie just to see how it would hold up and from this short exposure I can say: its been working great.
There is one hick-up playing videos on my Samsung TV where it jerks the screen every 10 seconds or so. Setting "PRIME RENDERING" to "EGL" solved this issue. (I did not experience this on my test monitor earlier, so ymmv)
Very impressive guys
NanoPi-R6C/R6S HDMI audio will be added in near future.
Update patch file is exist.
That is very nice to know.
I don't know this has been updated or not, sorry.
Don't be, I'm happy as it is now, it was unexpected to see things go as fast as they do. I think we get a fully working RK3588/s kernel in Linux 6.18 late December. Most likely small issues and quirks like these will be solved a bit later.
I don't even know if I would benefit from the extra RAM if its available
Thank you for your time
edit:
Update patch file is exist.
Is it this one: https://lkml.org/lkml/2025/8/7/872 ?
Works fine on the NanoPi-R6C except for audio ( no audio device detected )
Its very very very smooth, it hardly breaks a sweat. From the 8 cores playing a random MKV@1080p@x265, 7 are idling 0-2%, one of them jumps between 25%-40% and its a different core each time (a bit like whack-a-mole with one mole) .
CEC is detected, but in my work env i have no TV 
SMB works, NFS works
Booted right out of the box
Except for the audio this is one hell of a job guys
Thanks
edit: I found out that only 4GB of the 8GB memory is recognized
afaik the R6C came in two models: 4GB-no_flash and 8GB-32gb_flash
Hi,
When pausing a video I sometimes forget I was even watching due to some interruption. When returning I see the TV is still on while I like it to be off.
This is different from when a movie ends and you walk away, then I will find that my TV is turned off (after 10m) while LE is still idling.
Does anyone have an idea what this might be ?
Thanks in advance
