Here are two test images for RPi4 and Generic (GBM) that contain connman/iwd with latest patches/changes (HEAD):
https://chewitt.libreelec.tv/testing/LibreELEC-RPi4.arm-11.0.1.tar
https://chewitt.libreelec.tv/testing/LibreELEC-Generic.x86_64-11.0.1.tar
If others can confirm things are resolved we'll get the changes submitted and merged.
Could it be possible to create a Generic-legacy image for Virtual machines also?
No. The current image is created solely to facilitate internal dev/test work in vmware workstation/fusion and is not formally supported (and not on other hypervisors) so we have no desire to create more versions. If it happens to run anywhere else it's a coincidence, and if it breaks (and it does, because staff are not using it often) then we have no promise of fixing things.
At the moment there are still some add-ons and Kodi Omega plumbing bits that are not aarch64 compatible so we are deliberately omitting the config needed to permit successful crossgrade from arm to aarch64 images; and based on how future testing goes we might decide to not allow that anyway. As such the update from arm to aarch64 is being correctly rejected. If you make a clean install, the aarch64 images should run fine; albeit Kodi Omega is a pre-Alpha codebase right now.
In LE11 the keymaps need to be in toml format which is similar and human-readable but not the same as the older text file format. Have a look at existing toml files in the system and crib the format (the wiki article needs to be updated to show this).
It may help to have 1080p 60/59.94/50/24/23.976 modes whitelisted and adjust refresh start/stop enabled as it will eliminate or greatly reduce the amount of correction Kodi needs to attempt; as the decoder doesn't handle correction too well (same issue as seeking). There is no known list of problem media configs/types so nothing to avoid .. it either works or doesn't.
I'd be interested in a sample of the file for long-term testing with problem media, but currently there isn't anything I can do about fixing the decoder so my advice would be to transcode the file to H264.
frakkin64 the two patches I picked off the list are here: https://github.com/chewitt/connman/commits/invalid-key
An image for RPi4 with two additional patches from the connman list for someone to test. I have low expectations that either patch will resolve anything, but for the sake of a 30-second rebuild: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.1.tar
[Unit]
Description=ngroc service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/path/to/ngrok tcp 22
[Install]
WantedBy=multi-user.target^ something like that in /storage/.config/system.d/ngrok.service
Then "systemctl enable /storage/.config/system.d/ngrok.service" and "systemctl start ngrok.service" .. it should then be persistent over restarts and even upgrades (as long as ngrok itself continues to run).
Run "getedid create" with the system on/working and the EDID data from the HDMI connection is captured and cached so the HTPC will always see the AVR/TV as being connected. Much easier than scripts.
Over time the software packages we use evolve; normally adding support for new hardware and features, and occasionally doing spring cleaning to drop support for old hardware. The version of mesa we use in LE11 (mesa is responsible for 2D graphics like the Kodi GUI) has done spring cleaning since the version used in LE10 and the GMA950 card appears to be one of the casualties.
Options are:
a) Custom image that uses an older (pre spring-clean) mesa version
b) Disable onboard video (if possible?) and use a newer supported card
c) Stick with LE10
A is not guaranteed to be possible, but also not hard to try if you have some self-building skills. If tempted with B, pick a newer Intel or AMD card, not nVidia (else you are forced to use the Generic legacy version of LE). C is the easy option.
I've dug my own Hub out, and mine is definitely bad joints on the UART connector. If I press the connector from a certain angle (forcing the bad joint to connect) it boots fine. If the cable is just connected it always ends up in the u-boot console. In current state, that means it's great for experimenting with u-boot though.
Based on the total number of issue reports to this forum and our IRC channel I'm calculating this problem is impacting ~0.0009% of the users running LE11 images. That level of "failure" is excellent. Of course we would prefer it to be 0%, but as with most things in life 100% perfect is never realistic and/or would require so much time/effort and testing that some combination of "no fool would ever volunteer to the project" and "sorry, too busy testing to make releases" would apply. At some point you have to call time and cut the release. You are all welcome to roll back to something earlier if that works for you. You are all welcome to go play with Kodi on Android or Windows or .. some other distro too; if you feel we're doing such an intolerable job.
In reference to patches; the "service: Fix hidden service with wrong passphrase" patch is adding support for flagging an invalid-key, not resolving an issue where invalid-key is being flagged which is a subtle but important difference. IMHO the description contains all the right keywords to sound interesting but I don't think this is relevant. No harm in testing it though.
As nobody on staff can reproduce this .. someone needs to start sharing connman and iwd debug logs. They will be verbose and sizeable but are often quite human-readable. The issue is likely in the comms between connman and iwd.
If your network and the internet are good, the low-quality (or in current world situation, over-subscribed) pirate IPTV service is the issue and cache fiddling cannot resolve slow streams. Forcing Kodi to increase cache size just means you wait long for the stream to start and wait longer for the cache to refil and restart playback when the stream stalls. Удачі..
The Telos and Meta boards are based on the same design. I'm not saying that's the same design as your board (no idea). Start with the p200.
It looks like it crashes in the i915 graphics driver. I'm not sure why.. others may comment though.
Someone swapping their drives from NTFS to EXT4 would at least eliminate or confirm the issue is related to NTFS; if the problem goes away it's something in the in-kernel filesystem driver. If it occurs with EXT4 then it's something else.
The Telos/Meta variants are 2GB, the pro is 1GB; otherwise they're based on the same board design (derived from the P200 reference board) and have much the same features.
If all you want/need to do is edit files in the OS, enable SSH access and connect using PuTTY (on Windows) and use nano to edit files. It's a lot less hassle than (re)booting from another OS to make minor changes.