Posts by chewitt

    In our house there's quite a lot of subtitle usage and I don't see any issues with embedded subs or sub files in the same folder as the movie or tvshow being watched. If external subs are used I do ensure they are named the same as the accompanying media. I also download from opensubtitles. Again, no drama.

    Share a Kodi debug log from a clean boot, playing some media with subs enabled.

    It's not obvious but I'd guess that you are playing "HDR" media (as I can 4K HEVC in one of the snippets) and this switches the TV into an intentionally brighter output mode. As a direct result the OSD appears brighter too, as Kodi does not support changing the OSD colours to dim/compensate for the increase in brightness.

    Kodi debug log would confirm the media spec.

    I'm using an RPi5 with an LG 4K OLED set. I don't see these issues. I also didn't see them in the past with an RPi4 either. However I never enabled 4K@60 modes because I have no 4K@60 media other than a few test files, and I suspect that 99% of people enabling 4K@60 modes "because, more is better, no?" similarly have no actual need to enable them. I also have all the HDMI sockets on the LG enabled for deep-colour modes (which changes their HDMI capabilities) and I am only using 4K60 certified cables between RPi and AVR, and AVR and TV. I also follow the configuration recommended in the 4K-HDR wiki article (which I wrote).

    Some of the items in your initial descriptions read like "user didn't read the manual" issues. Others sound like insufficient PSU and/or cables - all of which are helped by NOT enabling 4K60 modes and using the right HDMI ports (they are not all equal).

    NB: We do occasionally see users complaining about media with weird encodings that an RPi board will not play, but that's usually media they stole/torrented so isn't something we care about investigating. If it's only a handful of own-source files that cause issues you can always use tools like Handbrake to fix the weird encoding and make things playable.

    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.

    Code
    /usr/share/kodi/addons/service.libreelec.settings/resources/lib/modules/updates.pyc

    Your 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.

    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.