PuTTY caches keys locally and you probably need to clear the cache. The disable passwords setting must be OFF too.
It would be a useful feature as Amlogic mainline also has MPEG2 HW decoding problems.
AMLGX includes this for a while now: https://github.com/chewitt/linux/…23a7a19f2d0ba9e
Add "textmode" to boot params and the board should boot to a local console instead of starting Kodi, and you can connect a USB keyboard to poke around and see if there are any interesting errors. You won't be able to start Kodi, but it will maybe help to prove/isolate whether the issue happens before or after Kodi start. I'd guess during/after.. but let's see.
This seems to hint at power issues: https://github.com/raspberrypi/linux/issues/4130
It's not possible to force connection to a specific band, the connection manager will prefer whatever provides the strongest signal. You might find that setting wireless regulatory domain helps the client device see all frequencies available on the router.
Any difference if the device is connected before power-on/boot? (prob. not, but will ask anyway)
Is there any other way of installing torrent client on LibreELEC ?
The danger of hijacking other people's threads is people get confused. The OP had an RPi3 .. and you have different hardware.
In both cases the current Linuxserver container appears to be armv8/aarch64 only which means it will not run on any current LE release. It will run on the LE12 nightly for RPi2(3) boards as we switched to aarch64 there. It will not run on any Generic image which needs x86_64.
There are probably other container sources out there if you look for them.
However this is the correct subforum and I already binned the other thread .. so you might want to revert your changes.
NTP is handled within ConnMan so making Kodi wait for network up won't have any effect.
I'd suggest setting a different NTP server in LE settings (an IP for time.microsoft.com or your local router) and seeing what happens.
Perhaps try adding "video=HDMI-A-1:1920x1080M@60" to kernel boot params in cmdline.txt (add to the current line, do not add to a new line)
Please to not post the same content in more than one place. I've kept this thread and deleted the other.
"What's the best hardware" is always a divisive topic, but unless your needs are something exotic, RPi4 is our go-to recommendation.
Something probably got bumped out of sequence and there's an API/ABI change to handle. Give it a couple of days and through general package bumping it will probably resolve itself. Thanks for the tip.
heitbaum ping ^
crazyturk issue is that AMLGX LE12 nightlies are still building with "arm" userspace while the general assumption in our buildsystem is that all ARMv8 SoC devices are now using "aarch64" userspace. In short, the common ARMv8 "arm" repo probably isn't being built and thus does not exist or best case it exists but is incomplete (missing all the binary add-ons) and thus you can't install them. If you look in a Kodi debug log it should be fairly obvious from the URL failures.
I will need to look at bumping kernels to Linux 6.5 and moving AMLGX to aarch64 .. I had been hoping to ignore that for longer.
RPi boards have no real-time-clock (RTC) hardware so 'dateTime' in the OS initially starts from the libc release date (in the LE image you're using this is a date in Febuary 2023) and then once the network is up an NTP request to pool.ntp.org time servers corrects dateTime. At least, that's what's supposed to happen. In your case boot looks normal and I can see the board gets an IP, but NTP isn't resetting dateTime so the clock remains in Febuary, and this means any website/service that presents a TLS certificate with a start date newer than the OS clock is seen to be in the future and invalid, which renders that website/service inaccessible; and this can be seen in the logs.
It's unclear why the NTP request is failing, but that's the cause of the issue. The workaround is to set the correct date/Time using the "date" command via SSH, but this will not be persistent over a reboot due to the lack of RTC chip on the RPi board.
Some ISPs seem to block NTP requests to pool.ntp.org servers, in which case another can be configured and used via the LE settings add-on or through 'connmanctl' (the connection manager utility). Many routers will also respond to an NTP request.
It doesn't sound like a software problem.
Kodi is not good with large file listings, but this is how Kodi is coded (and something likely changed between Leia and Matrix) so your options are to seek changes from the people who code Kodi (via the Kodi forum) .. or since everything is open-source, you can modify Kodi code and recompile things yourself (although few users will have the skills for that).
