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.
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.
Gismeteo comes from the Kodi repo so it's not our problem. The service probably changed something in their API and the add-on needs correcting. Go look at the Kodi forum support thread for the add-on for more info.
I don't see any libretro issues in the Kodi logs but Kodi retro-gaming stuff is still subject to changes upstream. If updates are made available we will pick them up automatically in the coming days.
Is there a way to build new, without a make clean?
Just run PROJECT=RPi DEVICE=RPi4 ARCH=aarch64 make image again. The buildsystem creates a stamp (hash) of each package folder containing build instructions and for the linux package this includes the defconfig files too. On running the build command the buildsystem will walk through all required packages skipping those where where the stamp remains valid and rebuilding any where change is detected; the stamp for linux will not be valid as the conf was edited so the package will rebuild and you'll have a new image. The image 'respin' time depends on what you are (re)building on; for me cross-compiling from on a 32-core x86_64 box a minor kernel change is ~2 mins.
NB: As a general rule you can avoid a full clean rebuild unless certain fundamental packages are changed; glibc is one of them but there are a couple of others I forget the names for. If the respin fails repeatedly or the result is bad a clean build is the best way to ensure stale packages were the cause. Simple rm -rf on the build.LibreELEC folder is faster than make clean.
If the driver doesn't support suspend then it's nVidia's problem because it's their driver, all we did is package their driver into our distro image.
It's not possible to install .deb packages but it is possible to unpack them to see what's inside:
ar x package.deb
mkdir /storage/deb
tar -xf control.tar.xz -C /storage/deb
tar -xf data.tar.xz -C /storage/debIf the tool(s) are a single binary, inspect it with ldd to see if it's a static binary or linked against shared libraries. Manufacturers tend to compile this type of tool as a static binary to make it self-contained and more portable across a larger group of distros; and if true, you can probably just copy the binary and run it on LE with some supporting scripts and a systemd service.
If the tools are a whole suite of binaries etc. then it's probably a dead end.
I gave support advice. You chose to ignore it. Your problem is not our problem.
This is the alsa conf that LE12.2 uses, it is focussed on HDMI output and the 3.5mm Jack output is unlikely to work:
I am reworking audio support for LE13 to hopefully to get pass-through HDMI audio working. I might play with analogue later, but it's not a priority for LE users so not a priority for me either. I have no interest in trying to support other distros like Debian - which has a forum where you can ask for help from people that understand its packaging and requirements.
LE13 dev images support installation of browsers via flatpak. There are test images here: https://chewitt.libreelec.tv/testing/ although the latest ones posted have some major improvements for video decoding and I have not tested them on S905X3 (SM1) hardware yet. Testing is $free though.
In future posts please use line-breaks in your text instead of posting one huge wall of text.