I did a little vacation fiddling for Radxa Zero support the other day so there are some 10.0 images on my share again. Kernel is 5.14rc5 and uboot is 2021.07.. but nothing apart from the Zero image is tested and there are no real-world changes to video/audio support although HEVC is enabled and may work on GX devices with 8-bit output (it will prob crash on newer devices or 10-bit media). Usual rules apply; I’m not “supporting” the images so if it works that’s nice. If not, there’s no need to comment unless you also found a fix for something.
Posts by chewitt
-
-
CE has never supported the Amlogic 32-bit SoCs so that’s not an option. Meson8 (S805/S802/S812) is slowly gaining mainline kernel support and we may release for them again in the future but there is no activity on Meson6 (8726MX) so LE 9.0 is the last and final release for WeTek Play 1 boxes.
-
Not that I’m aware of, but I have zero interest in torrent things (smells like piracy to me) so I’m not looking for anything.
-
I don't have any working devices with AML left, so I don't test or release them anymore.
Closing this thread. Please use Official LE Test Images for Amlogic (Kodi-19)
-
The video drivers in LE 9.2 are not functionally complete. Please retest with current LE10 images.
-
For HDMI devices the audio output properties in Kodi are determined from EDID data read (once) at boot time. Modern AVRs pass-through the EDID from the downstream HDMI device, e.g. projector or TV, so I'm wondering if the HTPC is reading EDID data from the AVR itself (as the projector is not on) and then after turning it on the HDMI properties change and cause some issue.
Have a look at the EDID output from "modetest" after boot with the project off, then reboot with it on. If it's changing .. follow the instructions in the wiki to capture and use a static EDID file so the HTPC always sees the projector as on (with the right EDID data).
No guarantees that's the issue, but we do see odd things when people turn things on after the HTPC sometimes. It's just a hunch.
-
The one that is being used.
-
To prove/disprove whether it's a connman bug someone needs to generate debug output so it can be shared with the connman devs for their investigation. Definitely a case of "No log, No problem" ..
-
-
Code
Display MoreFeb 02 11:29:49 koditv1 connmand[416]: wlan0 {update} flags 36867 <UP> Feb 02 11:29:49 koditv1 wpa_supplicant[513]: wlan0: Trying to associate with SSID 'IntelPrintServer' ... Feb 02 11:29:59 koditv1 wpa_supplicant[513]: wlan0: Authentication with 6c:3b:6b:12:f3:fb timed out. Feb 02 11:29:59 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:12:f3:fb reason=3 locally_generated=1 Feb 02 11:29:59 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD ... Feb 02 11:30:05 koditv1 wpa_supplicant[513]: wlan0: Trying to associate with SSID 'IntelPrintServer' Feb 02 11:30:08 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:12:f3:fb completed [id=0 id_str=] ... Feb 02 11:30:19 koditv1 systemd[1]: Finished Wait on network. Feb 02 11:30:19 koditv1 systemd[1]: Reached target Network is Online. ... Feb 02 11:30:29 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:12:f3:fb reason=6 Feb 02 11:30:29 koditv1 wpa_supplicant[513]: wlan0: Trying to associate with SSID 'IntelPrintServer' Feb 02 11:30:29 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD ... Feb 02 11:30:29 koditv1 connmand[416]: Probably roaming right now! Staying connected... Feb 02 11:30:32 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16 ... Feb 02 11:31:14 koditv1 wpa_supplicant[513]: wlan0: Trying to associate with SSID 'IntelPrintServer' Feb 02 11:31:17 koditv1 wpa_supplicant[513]: wlan0: Associated with 6c:3b:6b:12:f3:fb Feb 02 11:31:17 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:12:f3:fb completed [id=0 id_str=] Feb 02 11:31:17 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} address 192.168.17.31/24 label wlan0 family 2 Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} route 192.168.17.0 gw 0.0.0.0 scope 253 <LINK> Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} route 192.168.17.1 gw 0.0.0.0 scope 253 <LINK> Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} route 192.168.21.1 gw 192.168.17.1 scope 0 <UNIVERSE> Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} route 0.0.0.0 gw 192.168.17.1 scope 0 <UNIVERSE> Feb 02 11:31:17 koditv1 connmand[416]: wlan0 {add} route 82.165.8.211 gw 192.168.17.1 scope 0 <UNIVERSE> Feb 02 11:31:18 koditv1 connmand[416]: wlan0 {del} route 82.165.8.211 gw 192.168.17.1 scope 0 <UNIVERSE> Feb 02 11:32:27 koditv1 wpa_supplicant[513]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=PR
^ Is "IntelPrintServer" the correct SSID? .. print server hotspots are normally private (access to printer only) and not internet routable. I see no attempt by ConnMan to contact an NTP server, and if there is/was it would be logged.
I'd clean install to remove all current network config and start again.
-
The /etc/motd file is inside a read-only file that's uncompressed on each boot into a virtual filesystem, so MOTD cannot be changed without recompiling the LE image, see:
LibreELEC.tv/options at master · LibreELEC/LibreELEC.tv · GitHub
LibreELEC.tv/image at master · LibreELEC/LibreELEC.tv · GitHub
-
The default VPN confs used by most providers simply "route all traffic down tunnel" .. hence the issue. However, most containers are NAT'd on the local host so they only expose ports/services via the existing IP address/interface of the host. To fix this you'd need to run containers from anothre IP address/interface (can be a alias/virtual interface), and then fiddle with the routing rules in the VPN conf so that you only route all traffic for the main interface (excluding the container interface) down the tunnel.
-
Our default config uses pool.ntp.org servers so you do not need to configure anything for NTP to work; assuming your network or your ISP does not obstruct the normal process. ISP blocking sounds dumb, but appears to happen more often than you'd realise.
Clean boot, wait 2 minutes, then "journalctl | paste" and share the URL here so we can see what the system actually does.
-
Assuming you're okay at the SSH console and can read internet HOWTO posts on uncompressing a tar file (the backup). You can take a backup on LE 9.2.6 (using the settings add-on) and make a manual/selective restore of the following from the backup:
/storage/.kodi/userdata/sources.xml
/storage/.kodi/userdata/addon_data
/storage/.kodi/userdata/Databases
/storage/.kodi/userdata/Thumbnails
The Python 2>3 changes (and arch change) mean you need to reinstall add-ons anyway .. consider it an opportunity for spring cleaning. The scrapers are also different in Matrix so you can either take the highest numbered DB files and existing Thumbs cache and use it again or only copy sources.xml and then rescrape. The guisettings.xml file has other config, but some will be x86 specific so it's always 50/50 how that turns out when swapping arches. With practice it takes 5 mins to reconfig everything in Kodi settings so it's not a big deal.
-
-
The EXT4 filesystem and content of the SSD should be auto mounted by the kernel and visible under /var/media/<name/UUID of SSD> ?
-
Set the Kodi SMB client to min/max SMBv1 and restart Kodi and the NAS shares should be visible. There is no change in this since v9.2.6.
-
I wouldn't say dead, but I'm on hiatus for a while now since I don't have much free time for kerenel fiddling (busy in the real-world) and vdec development has been stalled for two years, so from a Kodi perspective there are no improvements to be excited about. There is still ongoing work on the Amlogic SOC platform overall.. the core OS is solid and increasingly used by industrial use, desktop and some of the retro gaming distros; but all of those have primary use-cases that do not depend on multimedia capabilities in the same way LE/Kodi does.