Posts by chewitt

If it works in one skin and not the other, it's a skin problem. Swapfiles will not be the solution.

That's best reported to the skin developers via Kodi forums. I'd guess there's something not updated in the skin for Omega final.

LE12 now supports configuration of the NFS chunk size; see if adjusting it up/down makes a difference?

connmanctl
agent on    <= this is important
scan wifi
services
connect wifi_b827eb3bee66_465249545a21426f782037353630204644_managed_psk
(enter pw)

I'd guess that you didn't set "agent on" to enable the d-bus agent, so when connmanctl attempts to configure things via d-bus the connmanctl client is "not registered" with d-bus and unable to send the message.

Kodi people run Kodi infrastructure. LE people run LE infrastructure. There was a disturbance in the force yesterday that caused wobbles with the Kodi mirror master.

Quote from deleonkikko

I am willing to collaborate as a tester as I have both boards. so I am available to anyone who needs me

The world is full of willing testers and devoid of people with the time and/or skills to write complex kernel drivers pro-bono.

Kodi got a little heavier with time and this is hardware from 2015. Running from eMMC storage will be a little faster, but I would focus more on whether the box is functionally okay with your media before taking that step (although restoring the factory Android image is simple). AMGLX is not perfect and some folks will be better off with legacy images.

LE11 will not improve anything over LE12 speed-wise and functionally it's a half-step backwards. Your call

RaspiOS probably has software tinkering to force the case fan on, and realistically it's more likely to be needed with a desktop OS that generates a lot more CPU activity than LE does. Baseline fan speeds and activation temps are controlled by Linux (defined in device-tree) and we're using the RPi kernel authored by RPi devs to work with their hardware and we assume they know what's needed. From personal experience 100ºF (38ºC) is nothing for an RPi5 board (mine runs with no case, no heatsinks, no fan, at 55ºC with zero issues) so I wouldn't expect a fan to be spinning up until a much higher temperature has been reached.

In case it's not obvious from the comment. There's no bug to straighten out, so you'll be in for a long wait.

reposting.. https://paste.libreelec.tv/premium-manatee.log

ay 08 17:03:51.389390 LibreELEC kodi.sh[1017]: libva info: VA-API version 1.17.0
May 08 17:03:51.389390 LibreELEC kodi.sh[1017]: libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
May 08 17:03:51.732002 LibreELEC kodi.sh[1017]: libva info: Found init function __vaDriverInit_1_17
May 08 17:03:51.733293 LibreELEC kodi.sh[1017]: libva error: /usr/lib/dri/iHD_drv_video.so init failed
May 08 17:03:51.733293 LibreELEC kodi.sh[1017]: libva info: va_openDriver() returns 1
May 08 17:03:51.733293 LibreELEC kodi.sh[1017]: libva info: Trying to open /usr/lib/dri/i965_drv_video.so
May 08 17:03:51.779033 LibreELEC kodi.sh[1017]: libva info: Found init function __vaDriverInit_1_17
May 08 17:03:51.791757 LibreELEC kodi.sh[1017]: libva info: va_openDriver() returns 0

So it tries iHD and the falls back to i965 ..

See if adding "video=HDMI-A-1:1280x720M@60" to boot params helps? .. I can see it's trying to use [email protected] and I've seen other issue reports with that weird resolution in recent weeks and despite users blabbing on about it being a native resolution for their old TV, I suspect Linux doesn't like it.

https://wiki.libreelec.tv/hardware/amlogic/wetek-hub-play2

If there is no uEnv.ini file in the root of the SD card you have not downloaded the "box" image.

Team Kodi infrastructure people would be responsible.

https://wiki.libreelec.tv/support/update

No idea, but I'd start with running a scan with Kodi in debug mode and tailing the logs to see if there's anything that can be grep'd in a future scan/run.

There are several tickets in the inputstream.adaptive GitHub which point to this being a problem they are tracking/working on. It impacts multiple widevine lib versions and multiple platforms.

There are several tickets in the inputstream.adaptive GitHub which point to this being a problem they are tracking/working on. It impacts multiple widevine lib versions and multiple platforms.

There are several tickets in the inputstream.adaptive GitHub which point to this being a problem they are tracking/working on. It impacts multiple widevine lib versions and multiple platforms.

Major version update normally triggers add-on updates (as new repo, with new higher-versioned add-ons available) but on first boot the existing old-version add-ons will start/run and then updates will happen. With LE12 on an RPi4 the LE11 "arm" CPU arch add-ons are no longer binary compatible with the LE12 "aarch64" userspace and don't run, spewing some messages. Once the normal wave of add-on updates are processed you have aarch64 compatible versions of add-ons installed and all is good again.

Raspberry Pi did not pay mesa; they paid a well-known and respected developer shop with tons of mesa experience. Work on the mesa changes needed for RPi5 was done 6-9 months ahead of product launch so that on announcement day (one month before public availability) a refined pull-request could be submitted to add mesa support. Similar things were done with essential Linux kernel and DRM (VPU driver) changes too, and their own firmware blobs were in a "final" and well tested state. The result was: on public availability date -90 it was possible to create a shipping/releasable product on an RPi5 board. Some of the LE staff had alpha boards earlier; but things were already at a point of maturity where creating an initial RPi5 image took me 58 mins from unpacking the board sample to booting a daily-usable LE image on it; and that includes 30 mins image compile time. I'm lucky to have a fast box for compiling on, but that speed and simplicity was really about RPi5 being derivative from RPi4, and RPi devs having all software in a usable state. Raspberry Pi understand that average hardware with amazing software support trumps amazing hardware with average software support.

Rockchip and most other SoC vendors simply don't understand that software-focus, it's not in their hardware-oriented corporate DNA. They still ship average/poor "Hey Mom, it booted!" quality Board Support Package (BSP) kernels with their new products. In the case of RK3588 it was also missing major subsystems like HDMI. The Engineering saying "You can have it fast or cheap, choose which one" applies; and Rockchip and other vendors consistently pick "cheap" and rely on "the community" to rework their BSP code and write missing drivers from scrtatch, then send it upstream to the kernel. They do have staff assisting kernel development, but the lions-share of the upstreaming effort is done by hobbyist developers in their spare time, or professional Linux development shops working pro-bono because they hope to gain in the long-term from acquiring expertise and reputation, and becoming the go-to destination for funded commercial projects. Those folks are amazing, but they understandably prioritise pro-bono work below anything chargeable, so the process still runs slow.

RK3588 shipped two-years ago this week. It is still 6-9 months away from a viable LE image with hardware decoding; although we will probably add support for boards in a "software decode only" state earlier. The same is probably true of RK3568 which does have easier decoder needs.

balbes150 has some LE images for RK3568 available. I can't speak for how things run; there's a language barrier and Oleg hides sources on bitbucket behind a terrible GUI and obscures development with "one month of changes grouped in a single commit" which complicates change tracking to the point where nobody can be bothered to make the effort.

There is also https://github.com/LibreELEC/Libr…ment-2097736658 which shows promise; though it sounds like codecs are still incomplete or missing if things are limited to 1080p (sounds like software decode or legacy VOP use).