Ok then, I am waiting for the other rpi to come.
In other news, wifi could not connect earlier, so I connected the cable and I retried it with connman. But this time, connman mentioned that it had the key stored and it showed its right value
connmanctl> connect wifi_bxxx_4xxx_managed_psk
Agent RequestInput wifi_bxxx_4xxx_managed_psk
Passphrase = [ Type=psk, Requirement=mandatory ]
PreviousPassphrase = [ Type=psk, Requirement=informational, Value=mywifikey ]
Passphrase?I asked a friend to lend me his rpi3b (not sure if it is the plus version) to do some more troubleshooting because its wireless connection inconsistency is driving me mad. Can I use the same sd card that contains the nightly for it?
Fresh pastekodi from the rpi. I waited for like 5 minutes for it to connect to the wifi, it didn't, so I plugged the cable, sshed to it and connected to the wifi via connman again. This time though connman asked for the wifi key, although it was already stored. And I did not remove .cache/connman/wifi_whatever beforehand!
The service wait-time-sync.service topped the systemd-analyze blame board with a massive 5 minutes and 30 seconds, much higher than the 10 seconds delay of kodi-waitonnetwork.service which was second. It is more than obvious that le was waiting for a network connection here.
Time for the x64 nightly installation to shine 
After 2^n reboots and 2^n-1 flicks of the wifi switch (yes, the laptop is so old that it has such a hardware switch), it finally showed the wireless networks. As for the wifi signal, you are right about its calculation. It show as ~10% weaker than on le 9 and 10.
At the first try to connect, it failed and complained about the key being wrong, while it wasn't. At the second try it was accepted with no issues and connected to my wifi. Instead of installing confluence and greek, I had the idea of upgrading to the latest nightly and after it rebooted it showed no connections again. Right now, 2-3 reboots later, there are still no connections listed in libreelec settings and there is no wlan0 in ifconfig 
Also, kodi-send --action=InstallAddon does not work, neither locally (run via ssh) nor remotely (run from my pc with the --host= parameter). I have already enabled remote control from applications on this system and from other systems.
Why does pastekodi return "no results to fetch" and sometimes it just gets me back to the prompt without this message or the paste url? I just run it 5 times before it returned the url eventually.
There you go though. It failed to connect wirelessly, so I connected the cable and sshed to it. I will do the upgrade to the new nightly now.
---edit
And it just connected automatically on the first boot with 20220603-98b9aa2. What if the wifi takes longer to connect and I am just too impatient to wait? However, I think 1 minute is enough time for it to boot and connect, given the fact that it also has to wait for network connection right before kodi starts. Right now, wait-time-sync.service and kodi-waitonnetwork.service top the board of systemd-analyse blame with 32 and 10 seconds of delay respectively, while the remaining services each have a delay of 3 seconds at most.
Build 98b9aa2 for the rpi2 is 0 bytes again. The same applies for 8 builds of 98b9aa2 under the rockchip folder.
Of course I booted with the cable connected. How else would I be able to ssh to it? You probably do not see any failed wifi attempts because as I said connman prefers wired to wireless and turns off wireless when wired is connected
I could not hold myself any longer and downloaded today's nightly from the hotdog folder. I have disconnected the cable since I managed to connect wirelessly a few minutes earlier and I am now waiting for it to upgrade and boot. If it does connect wirelessly, do you want a fresh pastekodi or do you want to wait until the wireless fails to connect again, so as to connect with ethernet AFTER it boots?
Please tell me when that change from wpa_supplicant to iwr was made. Or at least point me at the relevant commit in github.
---edit
It just booted to the new nightly and connected wirelessly. I will do my kodi stuff (= add more addons and repos) until you reply.
Ok, just don't complain about my third party addons and repos. They are not gonna be removed until I decide to stop using the nightly.
---edit
And it connected wirelessly after I rebooted the router. I am now searching the router's log for something like "access denied to mac b8xxxxxxxxxx".
You are right.The above was the output of
dmesg | pastebinit -because
dmesg | pastekodireturned some error. Anyway, I do not want to post something that includes kodi's log because I am now checking if or how some addons work on kodi 20. If there is another thing I can paste for you, I will.
Back to connman, which is still biting me back
connmanctl> connect wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk
Agent RequestInput wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk
Passphrase = [ Type=psk, Requirement=mandatory ]
Passphrase? thewifikey
Agent ReportError wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk
invalid-key
Error /net/connman/service/wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk: Input/output error
Agent request cancelled by ConnMan
Retry (yes/no)?The wifi key is obviously correct. I am now rebooting the router just in case.
If by logs you mean just dmesg, then yea. Here you go. It is connected via ethernet and it is right after a cold boot which failed to connect wirelessly (cold boot > no wireless > unplug from power > connect ethernet > plug power back). Please ignore the cec timeouts, it is not connected to the tv.
As for the wpa_supplicant vs iwd, when was this change made? I am still on yesterday's nightly (20220531-0e57a30) and I am waiting for new images to show up in the main folder of test.libreelec.tv (= not in the hotdog subfolder).
And now that I posted the dmesg, I will retry connman and if it won't work, I will remove the forementioned folder with the settings related to my wireless network and start over.
And connman just decided to bite me back 
It did not connect wirelessly at first, so I connected the ethernet cable and sshed to it to try connman like yesterday.
connmanctl> agent on
Agent registered
connmanctl> connect wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk
Agent ReportError wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk
invalid-key
Error /net/connman/service/wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed_psk: Input/output error
Agent request cancelled by ConnManThat input/output error is what I have been getting as a notification upon failed connection on libreelec since I first installed it on the rpi, back in 2019 and I always blame its poor wifi for it.
Note that the key is fine, I double checked it on /storage/.cache/wifi/wifi_b8xxxxxxxxxx_47xxxxxxxxxxxxxxxxxxxxxxxxxxxx_managed/settings, where it is mentioned as "passphrase" and written in plain text. And I have checked it like so in the past as well.
I am off to try zcat then. I went with the ventoy option first, but I ran on this issue here.
---edit
This is gonna take a while... The nightly does not list the laptop's wireless under connections and it can only connect via ethernet. Here is what lspci -k (because I thought it would use b43 instead of wl) and dmesg say about it, and it is identical to what le 9 and 10 say too
04:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4312 802.11b/g LP-PHY (rev 01)
Subsystem: Broadcom Inc. and subsidiaries BCM4312 802.11b/g LP-PHY
Kernel driver in use: wl
Kernel modules: wl
# dmesg | grep wlan
[ 7.143290] wlan0: Broadcom BCM4315 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)In other news for the rpi, I noticed earlier that the wireless gets disconnected once the ethernet wire is connected. Disconnected as in "it no longer appears on my router's connected clients list". I assume (and hope) this is some connman setting that prefers wired over wireless, so it disables it.
Unlike ssds, where I have used products from all those 3 manifacturers and I am equally satisfied in terms of vfm (because samsung ssds are quite more expensive) from all of them, I do not recall using a samsung sd card (or a usb stick) ever. However, they always were an option when I was searching to buy one.
About the x86 img.gz files. Can I flash them to a usb disk by just running
zcat le-something.img.gz > /dev/sdcor, assuming I have extracted the img file from the img.gz,
dd if=le-something.img of=/dev/sdc(as a root that is). I am too busy to reboot my system to windows and use rufus right now.
Ventoy is a tool for creating bootable usb drives that boot straight from iso or img files. You install ventoy on the stick, you copy any iso or img on the stick, boot from it and ventoy allows you to boot the system from any of them by mounting them first. For me, who has been using isos on usb sticks since pcs allowed booting from usb, it is a real lifesaver.
I am 100% sure ventoy can boot the le img file because I tried it on a very first nightly of le 11, when it was still on kodi 19. What I do not know is if it can use persistence, because it would be mandatory to store settings, i.e. my wireless network and its key.
If not, I will have to use another stick, because the ventoy one has isos in it, and flash the img with rufus.
File system corruption has happened once (maybe twice) since I reflashed the img file on the card. I check dmesg for relevant messages a few times a day and I have not seen a sign of it for days now. And I boot the rpi like 5+ times a day
Also, it is not for the cost of an sd card, its for the wasted space. The 32gb sd card that came with my rpi3b bundle was like 95+% empty (not counting the default 5% of each partition size that is reserved by ext4) back when it had le 9 on it, because I was only using it for streaming. It only had ~200mb of the le installation on mmcblk0p1 and like 100mb of kodi stuff on mmcblk0p2.
In other news, I continue troubleshooting the wifi, so after it did not show up in my router at today's first boot (right next to the router, so wireless quality was 100% surely), I connected it via ethernet and sshed to it.
Then I had the idea of reconnecting the wireless interface via connman, so I followed arch wiki's instcructions here*. And it reconnected without asking for the key, which means that connman had stored the network credentials and skipped the last step completely. 2 cold boots later and it still connects wirelessly with no issues, but I will wait and see how it goes this afternoon or tomorrow.
Please inform us when all the images will become available only from the hotdog folder. Also, please add a releases.json for each subfolder, for the ones that want to use it as an update server for the nightlies.
If le 11 can boot from ventoy AND work in persistent mode, why not.
As for the rpi, probably not due to my lack of sd cards
I just noticed the following. While disconnected from the wifi, if I go to libreelec settings > connections > my wireless network, the options say connect, edit delete and refresh.
Notice the ones that say edit and delete, because they mean that the wireless network is already stored in connman's settings. For a wireless network that is not stored, e.g. my neighbor's, the options are only connect and refresh.
When clicking connect on the first situation, i.e. when the network is already stored, the user is asked to reenter the wireless key.
So i moved to the old laptop, which is like 2m away from the router and has very good signal, to check what happens on le 9 and 10 (both x64) under the same menu. I disconnected from the wifi, clicked connect and both installations did not ask me to reenter the wireless key. Could this be a bug of le 11?
I am asking because it is really weird to have the rpi right next to the router, with 70/70 signal quality (as reported by iwlist scan) and sometimes having to use the cable because it does not connect automatically.
Another run of memtester was completed with no issues on Saturday, but I forgot to report back. I connected to it wirelessly, did the upgrade to 20220528-84fdbeb on Sunday and nothing else for that day.
And today, I started the day (Monday 30th of May, ~7am) with testing. I got the rpi next to me again, powered it on and even after 2 minutes it was not visible anywhere. Pinging its .local name (I use zeroconf everywhere on my network) returned that the host is unreachable. It was not visible under the router's connected clients too, so I unplugged and replugged it.
Same thing happened after the reboot, so I had another idea. Leaving the rpi on the same spot, I tried the sdcard with lakka on. It booted with no issues, connected wirelessly and I could see it under connected clients. I ssh-ed to it and shut it down properly.
Then I got an ethernet cable and connected it to my router, hoping to get a reliable wired connection. It showed up for a few seconds under connected clients and it suddenly dissappeared. Disconnecting the end of the cable from the rpi's end only and reconnecting it gave a stable wired connection. I ssh-ed to it to run ifconfig -a only and saw that the wireless was completely disconnected!
I sweared a bit and moved on for today's upgrade (20220530-2d50f5f). I downloaded the tar file, checked its sha256sum, it was correct so I rebooted. And after the reboot it was still on yesterday's version...
I connected ssh-ed to it again to start over and while it was downloading the update file again, it got disconnected and reconnected with a different ip! First time on wired it was 192.168.1.142, second time was .143 and third time it was .144.
I know from experience that *elecs request a new ip from the dhcp server although their lease time has not passed (I have mine set to 1 day), so the above is now normal behavior.
The file was downloaded completely, its checksum was checked again, it was correct again, but no update happened again. I am now downloading it for the third time and I will give up if it fails again.
---edit
Oh look it worked! And with that third try, I am now on 20220530-2d50f5f after 30+ minutes of trying something that would take 5 at most.