It's been dropped from Kodi and we keep forgetting to merge https://github.com/LibreELEC/serv…ttings/pull/322 to solve the issue. I've now merged it, but the add-on (which we embed) now needs bumping in the main repo. That'll likely get done in the next couple of days.
Posts by chewitt
-
-
LE does not use/store profiles for iwd, only for ConnMan in /storage/.cache/connman/ .. but the correct way to store those is to use the connmanctl agent. The only time I've seen issues with passwords not being retained over boot is with WiFi devices that have no persistent MAC; so the kernel auto-generates and assigns a new one on each boot and since ConnMan stores profiles against the MAC, on reboot the MAC changes and there's no store profile and you're forced to configure it afresh. I do also see isses from users trying to use overly-long passwords too, but that's usually a more simple rejection.
Are you using the onboard WiFi of the RPi4 or some cheap USB dongle?. Check the MAC before/after rebooting.
-
No ideas on the change, but look at /storage/.config/system.d/wireguard.service.sample for a general template for how to run a shell command that applies a routing command on boot.
-
further, the focused/selected item is more bright, in compare of none playback. the brigtness issue happens at every movie file.
I honestly have no idea what you're referring to. All I see in the images posted is normal-looking GUI.
Post images without large white blobs. Unless you're watching pr0n nobody cares what you watch.
-
Code
/usr/share/kodi/addons/service.libreelec.settings/resources/lib/modules/updates.pycYour next two challenges being:
a) This file is inside the read-only SYSTEM file that's decompressed to create a virtual filesystem on boot.
b) This is (pre)compiled Python code, so it's a binary not an editable text file.
The issue stems from https://github.com/dtechsrv/Libre…05/options#L162 and similar config for all the other Amlogic legacy build devices dtech is supporting. It needs to be changed to HTTPS in the buildsystem and then the image(s) recompiled and released to include that change. I'm not sure it's worth the effort just to remove some log noise though.
-
Shielding probably isn't the issue, but mechanical issues seem to be common once people add connectors and extenders. At the end of the day ..
-
Why shouldn't it be possible for Libreelec to do the same for the proxy settings?
It's not impossible. It's just unlikely to be implemented because, a) few people use/require local proxies and you're probably the 2nd or 3rd person that I can recall wanting to use them in the last decade, b) it would require Kodi patching and we try to minimise that, c) there's a simple workaround (as you have now implemented).
-
Errors in log files do not always mean something bad. LE/Kodi does not support HDCP so the DRM display pipeline does not support SecurePath, so that fails and widevine will not be able to show 4K content. However, widevine will then fall-back to a non-secure path with limitations (1080p max) and show something (which it does). TL/DR: Ignore the misdirection.
-
regarding hardware acceleration, with the original Tv Box´´´´ s Android 4.4.2 it works perfectly with the app Airscreen, it plays perfectly at 1080p x265 from UMS on a PC through WIFI 2.4. Maybe this information helps to find a solution.
The upstream codec drivers (in the staging area of the kernel) are incomplete and do not support Meson8 hardware. Knowing it works on a prehistoric vendor kernel from 2010/11 doesn't help with that.
-
it would be interesting if the Chromecast could be ported to the TV Box. I have the first one from 2013 and it still works perfectly with all the streaming apps. Is it possible to do that?
Google provides sources for all the open-source software they use in their Chromecast devices. However, and very intentionally, they provide sources without git history so you cannot easily see what they changed, and they don't provide sources for any of their own-code bits (which remain closed-source). There are also Amlogic kernel sources for older boxes and you can grab the latest AndroidTV or AOSP sources (which are public) so could in-theory create a newer Android release, but mating them into something that boots, runs, and is reliable, will required deep technical skills and several thousand man-hours of effort. Good luck
-
The correct solution is setting the TV to 'auto-scan' instead of overscanning, but if that doesn't work Kodi has a manual calibration function. Note that manual calibration needs to be repeated for each resolution/refresh combination that you whitelisted (or each combo where the TV shows the problem) by setting the desktop resolution to that combo and then calibrating. Again, the better option is using auto-scan.
-
It's working here on an iPhone 14 (17.6.1) using Librespot and normal Airplay streaming. I'm technically using an LE13 image and an RPi5, but the Kodi version is from before the bump to Kodi piers (i.e., the same Kodi version as LE12 images), the Liprespot add-ons are essentially identical, and RPi4 vs RPi5 makes no functional difference. NB: Airplay streaming generally works better, there's less lag on playback, but I assume that's not an option if using an Android phone.
-
Nothing in the logs (as expected). Since Intel drivers are involved (and them having such a wonderful reputation) take a backup and bump to the latest LE13 nightly which is now running Linux 6.10 (so newer Intel drivers). I'm grabbing at straws a little, but there's logic to the request.
-
How does the Android running Chromecast 4k do compare to LE on RPI4B for video hardware acceleration or graphical UI?
Does Android use OpenGL or Vulkan for this?
The Chromecast has an Amlogic S905Y3 chip with Mali G31 GPU inside and supports OpenGLES. It's a faster chip than the Broadcom SoC in the RPi4, and the OS runs from internal eMMC storage, but Android has a much greater general OS overhead so I usually find the Kodi GUI runs "about the same" on most Android devices with my (large) media collection as it does on an RPi4B's inferior but less loaded hardware.
Hardware Video Acceleration is something different. RPi4B supports only H264 (to 1080p) and HEVC (to 4K) whereas the Chromecast supports a much wider range of codecs. That said, most of the extra codecs Chromecast supports are legacy ones and the RPi4B can software decode the legacy media using them. The main real-world difference will be VP9 media support.
Note that RPi5 significantly outperforms RPi4.
-
Share a full debug log file .. it will contain more info on your setup.
-
The bug I am referring to in that thread is this one https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10199
I've no idea what the issue you're seeing is, but I'd ask that you try updating to a current Generic (non-Legacy) LE12 nightly to see if any of the changes pending for 12.0.1 make a difference?
-
Only major pain in the butt I really encountered was Windows' habit of assuming it's the only OS on the disk
Yup, Windows does that. What to do
-
The GPLv2 Linux kenel is considered to be pure code from a license perspective, so loading an external vendor module that often has no license or some proprietary license "taints" the kernel's purity. In short, the messages are harmless.
