Start with an update to LE13, then if nothing changed run journalctl | paste after demonstrating the problem and share the URL
Posts by chewitt
-
-
So if you are buying an RPi5 for this fork go with the 2GB version, even the 1GB version should work if you can find it.
The RPi5 1GB model will not handle 4K media properly due to the RAM size so unless it's a dedicated 1080p/3D device, the 2GB model is our minimum recommendation.
-
I pushed a set of updated images to my test share. Kernel is 7.3-rc5 and Kodi is v22-rc1.
Known issues are limited to:
- GXBB support for HEVC/H264 is capped at 1080p pending further research into HDMI stability at 4K
- GXBB/GXL/GXM have multi-threaded bwdif software deinterlacing (still a nice improvement on bob)
- MPEG1, MPEG4 and VC1 are software decoded until we author the kernel UAPI(s) to implement around
Otherwise all the important stuff: H264/MPEG2/HEVC and VP9 and 10-bit/HDR where hardware supports it, and pass-through audio, are working on GXBB, GXL, GXM, G12A, G12B, and SM1 hardware. If you find media that refuses to play, or glitches/crashes during playback, we'd like a sample file to investigate.
Image name changed from "AMLGX" to "Amlogic" so do touch /storage/.update/.nocompat before rebooting.
Enjoy
-
Is this ‘compression’ also backwards compatible?
No .. but Yes
Older images will not recognise filename.tar.zst as something valid to import, but run unzstd filename.tar.zst and you end up with filename.tar which they do recognise, so it's not a big deal.
-
Kodi logs aren't going to capture any useful information for a WiFi issue. The problem is way below Kodi in the software stack and you'd need ConnMan and IWD in debug mode to capture anything in the systemd journal.
All of which is moot when the most likely cause requires 10 seconds of effort to run one CLI command, and then reboot.
-
Yes, correct. It's now zstd compressed and saving you space.
-
Will the nightlies work on Ugoos SK3 powered SoC RK3588S2-DV and 8/128 GB on board?
I don't think so. I've not seen any mention of RK3588S2 support in the upstream kernel (only RK3588/RK3588S). The SoC differences are likely minor, but as there is no u-boot defconfig or board dts in the kernel for that box, LE will want to see those pieces in-place before offering support. NB: AFAIK there is no 8K support for RK3588 at the moment (in the to-do list, but not at the top) and DV will likely require some proper reverse engineering. I wouldn't rush out to buy one just yet.
-
Test the modprobe file please.
-
LE 12.2 or LE13 nightly? .. If on LE12 still, update to LE13.
-
Code
echo "options brcmfmac feature_disable=0x2000000" > /storage/.config/modprobe.d/brcmfmac.confIf you run that ^ over SSH and then reboot, does this restore previous behaviour?
This should functionally effect a revert of https://github.com/LibreELEC/LibreELEC.tv/pull/11785 which is a direct feature/capability change for the wireless stack that would have rolled out in RPi5 nightlies around September 19/20.
HiassofT FYI
-
I went for 4GB to be safe, have enough headroom for heavier skins, larger movie/TV libraries.
Heavier skins tax the CPU, GPU, and I/O performance, not RAM. Libraries do impact on RAM.
An NVME HAT with a small M2 drive is a nice upgrade.
-
dale I'd guess some changes are needed in the kernel. I'm currently up to my neck in Amlogic things but will add it to Claude's worklist once I circle back on Rockchip topics.
-
There is no forum rule banning CE from being mentioned. However comparison discussions have a habit of attracting trolls, and we prefer to avoid that kind of behaviour. Just keep the discussion sensible.
-
It has 32 GB of flash storage and (theoretically) 4GB of RAM, but LE can only see 3 GB, I still don't know why.
Open the box and see whether you have 2x 2GB or 3x 1GB DDR RAM chips on the board. The 3GB RAM config is quite common on Android boards, with stickers lying about the installed RAM size (and Android hacked to show 4GB) also not unusual.
-
Code
RPi5:~ # sysctl net.ipv4.tcp_window_scaling net.core.wmem_max net.ipv4.tcp_wmem net.core.rmem_max net.ipv4.tcp_rmem net.ipv4.tcp_window_scaling = 1 net.core.wmem_max = 4194304 net.ipv4.tcp_wmem = 16384 16384 4194304 net.core.rmem_max = 4194304 net.ipv4.tcp_rmem = 16384 131072 33554432Default values from LE13 at current master branch HEAD state ^
-
What hardware are you trying to use?
-
The cleanest route would be zero'ing the boot media first as that clears backup tables too, but that can take ages on a large sized drive and it's not essential. DD'ing the image (after gunzip'ing) overwrites/nukes any pre-existing partition and filesystem state so formatting first makes no real-world difference. No wiki hint required.
-
Edit the syslinux.cfg file in the LIBREELEC partition on USB/SD boot media and add ssh to the boot params line. This will force the daemon to start on boot. However if this is a clean LE12.x install, something is wrong for the add-on to be faulting or not running and SSH access probably won't solve that, and I'd recommend retesting with a current LE13 nightly first.
