LE10 > LE11 is a supported direct update. Only LE 9 > LE10 was blocked due to the Python 2 > 3 change.
Share logs. Our ESP is pretty bad.
LE10 > LE11 is a supported direct update. Only LE 9 > LE10 was blocked due to the Python 2 > 3 change.
Share logs. Our ESP is pretty bad.
I pushed a minor tweak to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar so you can update and share dmesg again (please) but the previous log you shared shows the audio card as detected in the kernel and Kodi and once you ignore all the stalker.pvr noise in the log; the stream you played shows normal 2.0 alsa audio output. So from logs all looks normal ![]()
The "special://" URI prefix maps to the root of where Kodi writes data, e.g. /storage/.kodi .. but that's a Kodi internal thing so firstly OpenVPN doesn't understand it, and second askpass doesn't accept URIs as input only paths.
If an absolute /path/to/the/file isn't working it might be relative, e.g. if JimH.ovpn and user.txt are in the same folder, only add the filename alongside 'askpass' and don't add the path.
If that's not it you probably need to look into (or share) the OpenVPN log. I've never used that add-on but I'd guess it generates a log somewhere and that might have more info.
LE11 "Generic" now uses GBM graphics not Xorg so there is no nVidia support. You need to update use the "Generic Legacy" image which does use Xorg and has nVidia support.
Have you tried using Tubed? .. it's a little less featured than the YouTube add-on, but sometime simplicity is a benefit.
Please put Kodi in debug mode then update to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar and share the URL from "pastekodi" after playing something. I'm not seeing anything unexpected/wrong in the system log but let's see what more logging shows.
The BT device probably uses VID/PID identifiers that aren't recognised by the kernel driver. LE 9.0 is no longer maintained so there's not much we can do to add them.
Have you tried the upstream kernel AMLGX image on a spare SD card? - It's not as feature complete as the legacy kernel images but with simple media collections it's often quite usable. Have a read of the LE 11.0.4 release notes for more info.
dmladenov I was working on the same change but you beat me to the announcement. It's good to know it works ![]()
As per https://github.com/chewitt/linux/commits/amlogic-6.7.y I've added "meson-gxl-s905l-p261.dtb" to the "box" image in my testing share: https://chewitt.libreelec.tv/testing/ so please switch to that dtb then share the URL from "dmesg | paste" and we can what else is working or not. NB: WiFi will not work because there's no upstream support for the MT7668 chipset. You can also follow https://wiki.libreelec.tv/configuration/…ration-advanced to create a working keymap.
I've been using Tubed for a while but had to resurrect the main YouTube add-on last week to test something. Once I fixed OAUTH login issues with my personal keys the YouTube add-on was preferring VP9/AV1 media at 4K/59.94 which was a) too much for an RPi5, b) not how things were configured in the past. After some config review to limit things to 1080p again, all was good. That sounds rather similar to your experience. I'd hazard a guess that 10.x with Matrix uses an older version of the YouTube add-on and with the 11.x update to Nexus the add-on has bumped to current and revised defaults/options and changed something.
I'd start with investigating the deprecated option warning which is related to ciphers; if those aren't aligned it will probably explain the authentication failure. The other messages are warnings (not errors) but also point to the config being misaligned with newer versions of OpenVPN that we're using. You should probably direct Q's to the VPN provider as it's their config which needs changes not our distro image.
I did reach out to HK but got their standard-ish "oh this is no longer sold.." response which basically means they no longer care for support (outside of their legacy kernels) and as usual support is entirely up to the community.
According to past Googling on the topic, S905L is the same as S905X except for no VP9 support. I did create a device-tree for a "Venz V10" S905L box before but the user disappeared without providing feedback so I've dropped that from my kernels.
The only odd thing in dmesg (other than references to missing SYSTEM file) is there's no sign of the GPU driver (lima) loading, but how that might factor into anything is anyone's guess. I don't see anything particularly odd from the vendor logs. I'm not much of an expert on them though and they're so full of verbose messaging it's hard to see much.
If you can't get the box to boot with Legacy LE or CE images then there might be something hooey going on at a low level (u-boot) which then upsets or interferes with Linux. It's hard to comment further from the info available.
In short.. ![]()
Kodi reads the EDID data to determine resolutions and audio capabilities once at startup and never checks again. One of these days that might change, but that's how the current implementation works. The forced EDID at kernel DRM level means everything on the Linux side (all the way up the code stack) is blissfully unaware that anything on the HDMI connection changes/changed.
I suggest you read LE 11.0.4 release notes first. If that doesn't deter you, read https://wiki.libreelec.tv/hardware/amlogic
Cache fiddling can sometimes smooth out the drops/glitches in WiFi, and other times it can't, but if it can it's free. I've also used an old router in bridge mode to traverse longer distances than the weak-as-hell onboard WiFi that lots of boards (not only RPi flavoured ones) have these days. Even old routers usually have better antennae and more receiving power.
Both logs show that playback starts in 2.0 pass-through then TrueHD/DTS-MA are detected and AESinkALSA renegotiates to output with 7.1 output. Kodi appears to be doing the right thing here. What spec is the HDMI cable?