Test the modprobe file please.
Posts by chewitt
-
-
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.
-
If dd was used correctly, writing the LE image to the card overwrites the first 512MB and the first sector (512 bytes) contains all the primary partition and filesystem structures that describe layout. It will leave backup partition tables intact at the opposite end of the drive; but that's true of your magic formatting step too.
-
like the infamous 12/10 bit issue on N100
Which has been patched in LE13 images for quite a few months now..
-
It's a moot point. If one person (or LLM) is the analyser of the existing design, writer of the specification, legal reviewer, and clean room implementer the result is almost certainly not clean. See https://en.wikipedia.org/wiki/Clean-room_design
-
In the v7 submission everything below the first paragraph should have been placed under the --- separator so that it is visible to reviewers but not merged into the codebase along with the description.
I normally place things above --- during development so that testing commentary is easily edited and not forgotten, but then you need to remember to tweak the final patch files before sending to move the --- above it.
-
I think that there is a problem with the auto switcht feature. If I set a screen as prefered, It should be used the moment the screen is available. I would say this is a bug.
This was merged in Kodi https://github.com/xbmc/xbmc/pull/28633 .. and you will spot me clearly calling out that this feature is not working as it needs to, but it was merged anyway. Technically this is not a bug because the [bad] code is working as [badly] designed; and that incomplete design will be extended in K23. I predict the fix to be invasive; lots of things need to be touched, so it's unlikely we can backport anything to K22.
Our current plan is to hide the setting in the GUI to stop people using it and then complaining it doesn't work as they expected it to work and how it needs to work.
-
It all depends on how the implementation has been done. If Astra decided to decompile/reverse Dolby blobs then the outcome is illegal. If it's been done under "clean room" conditions (which arguably might be impossible with AI agents that learn from other users input) then it's probably harder for Dolby to challenge. Either way, the moment source code that works is posted or leaked somewhere things will be interesting.
-
I got it. Since you don't have any competition, we have to shut our mouths. I do
There are 20+ major distros that have a Kodi package. You are not forced to use LE; whatever works for you work for us.
I did ask you to test the current LE13 image, but you refused. Triage 101: first eliminate all the bugs and issues fixed since the release the user is running by testing the current development release. Nobody has been developing the LE12.2 codebase for 18-months beyond bumping add-ons so even if a problem was identified it will never be fixed in that release.
And nobody told you to shut your mouth, but we are all volunteers working in our often-limited free time. If you can't be arsed to help us with basic testing and information, we can't be arsed either.
