Posts by chewitt

    If the 4K/UHD rips you make are HEVC then the RPi4 should handle them fine, and is free since you already have it. RPi5 is faster in GUI nav and a few other things but that's spending $$. I haven't used Intel hardware in years so can't make a recommendation on that side (RPi5 is the daily-driver).

    What is now the next step for this issue?
    Will your fix get merged into the main libreelec repo? Or will people with newer intel cpus be dependent on your fork?

    It's a workaround not a fix, so further investigation is needed to identify and resolve the root cause. Links to the Intel DRM issue tracker were posted already. The Intel devs that you need to contact are probably lurking in the #alsa-dev IRC channel on Libera and/or the #linux-media channel on OFTC too; but start with formally recording the issue on the tracker.

    SD card issues appear to be resolved, but I haven't pushed the changes to the main LE repo yet; hence not in nightlies. I'm using a newer kernel than the rest of LE and some breakage in shitty Realtek drivers need to be resolved before I can push the Linux 6.7.0 kernel bump to the main repo. NB: We don't need "testers" we need people that write kernel drivers :)

    The settings add-on provides a backup/restore function not a backup/migrate function so "everything is working as expected" from our perspective. You need to clean install on the RPi5 then copy the .tar file to the device, unpack it, stop Kodi, then selectively move the bits you care about to their required locations and restart. You may find that you need to create/setup a passwords.xml file to go with sources.xml if you updated from a much older release. Otherwise things should work. In library views the /path/to/file detail is only shown under the "refresh" icon.

    There are lots of different software RAID options. If we add one type for one (small) group of users we'll have to add more types to appease all the other (small) user groups that want something different. Then if we add 'only' the kernel options users will whinge about not having all the userspace tools that are needed to safely use and manage all the different RAID types and use-cases that come with the topic. This compounds the opportunity for complex support issues and increases the software maintenance burden and image bloat (the death of a thousand cuts) for the distro; so the project has always (since early OE days) resisted adding RAID support. Fortunately the distro is open-source with an excellent and simple build-system, and you are welcome to modify it as you like.

    This patch is needed to revert a change that causes glitchy playback and other issues on several platforms https://github.com/chewitt/LibreE…rt-fences.patch

    I'm waiting for RPi devs to figure out something with deinterlaced support, then I'll push that patch, a kernel bump to Linux 6.7.0 and few other changes up to the master branch. I forget whether the files currently in my test share have that fix included, or also include something that stops deinterlaced media playback from working .. you're welcome to experiment:

    Index of /testing/

    Two suggestions:

    Test again with an LE12 nightly image to see if the issue exists with Kodi 21 (Omega). I'm not expecting there to be a major change between K20 and K21, but it's important to know as development is now focussed on K21 (and will soon shift to K22).

    If the issue does exist in K21 it needs to be reported to Kodi developers via the Kodi forum as changes to the DLNA code are not something that LE devs have created; all we do is bundle upstream Kodi into a convenient distro image.

    H3N7R1K If you expected this experimental and developed-for-free (nobody charged you money) image to do anything more than boot (which might be pushing it on some hardware) you have rather inapropriate expectations. As the tone and language of your post were also not appropriate for the forum, it has been deleted.

    The sequence would be: Stop container > Restart Docker > Start container .. not just restart Container or Docker. No ideas if that's the issue but I've seen similar things in the past (and admins restarting things in the wrong sequence resulting in no change).

    The A95X-F3 has an upstream device-tree file (authored by me) so the current AMLGX image is usable; with caveats that accompany G12A/B and SM1 boards (read the LE11.x release notes for the info, nothing changed). Read the Amlogic page in the wiki for install instructions: https://wiki.libreelec.tv/hardware/amlogic.

    WiFi and BT won't work due to the MT7668 chip having no upstream drivers. The FireTV driver from the kernel mailing list Q&A is here: https://github.com/chewitt/MT7668 but I could never get it to compile in a usable form. Hence the repo is untouched and I archived it a while back to drop a hint to people that kept cloning the driver and asking how to compile it. I had a brief look at the ophub driver and that looks similarly bad to the one I found before. The guy that "figured it out" doesn't sound like he really figured it out either. I can't see an email for him, but his name is reasonably destinctive and Google shows the same name associated with some postings to kernel and freedesktop related things so he's probably traceable if you ask around.

    I never looked into LED lights on those boxes either. The clock display might be do-able but for the light ring .. I'd need to see the original Android dts file or decompiled dtb to comment further.

    The backup function in the LE settings add-on captures /storage/.cache, /storage/.config, and /storage/.kodi ONLY .. anything else that you put on /storage (including tar files in /storage/.update) will not be backed up. If you want more comprehensive backups; use the Kodi backup add-on or write your own backup script (and automate with cron or a systemd timer).