Posts by chewitt

    The cause is not clear, but it crashes shortly after starting, and in one log very-shortly after add-ons are loaded; so I'll guess the cause is an incompatible add-on (perhaps not updated for K22 alpha).

    Skins (and the many add-ons they depend upon sometimes) are a common cause for major crashes, so perhaps delete the skin add-on to force Kodi to default back to Estuary and see if that helps.

    If not, you need to hunt down the problem add-on. Stop Kodi, rename /storage/.kodi to /storage/.kodi-old and copy essential config over, e.g. sources and add-on settings. Then restart kodi and start reinstalling add-ons from repos. Either it all works (problem solved) or at some point you install something and problems start; then you know which add-on is the cause.

    Hauppague are a reputable manufacturer with good upstream kernel support, and Sundtek have well supported userspace drivers that don't depend on the kernel, which makes life easier. I can't speak for whether they are cheap or not, but they should work with LE well. If you go cheap, you're more likely to need a separate device for the server that can run a specific distro/kernel someone hacked up the drivers for, instead of using LE.

    The OP was about wanting to use internal storage. That’s normally a good indication people don’t want things hanging out of USB ports.

    NUC’s are historically great; right up to the point LSPCON chips appeared and started causing HDMI problems. They remain great; as long as they work. However we see continued issues that go unresolved in drivers and firmware, and if we can’t guarantee something will be hassle free we can’t recommend them.

    My normal go-to recommendation is an RPi5; never the highest spec, but with the best software support. That’s not really fitting the bill though, although these days there are some crazy ‘PC’ cases that you can run a pile of storage from.

    I come back to “if it works, don’t fix it” so keep the current HTPC and just get a NAS to handle data. I’d always recommend using a proper NAS not DIY kits or a pile of USB drives, because I value my data, and I want to use a NAS not add more to the list of things I have to actively maintain.

    The blanking is loss of sync on the HDMI connection. Common causes are using bad HDMI cables, bad HDMI adapters, the HDMI connector (the DRM device in the kernel) being forced to output using a mode that's outside the display device specs (can happen when EDID data is incorrect or has been incorrectly fiddled with), or the hardware being rubbish, and inadequate power supplies.

    In general I would set this:

    • Force the initial DRM state (as above)
    • Set the Kodi desktop to 50Hz
    • Set 'adjust-refresh' in playback options
    • Enable the whitelist and only select 50/60Hz 1080p resolutions
    • Enable rate doubling and 3:2 pulldown

    No idea if that will work though. In general I've always found monitors to be a bit rubbish compared to a proper TV.

    I'm no expert on Allwinner hardware, but I had a quick look at the device-trees in the Linux 6.17 kernel source, our current Allwinner patchset, and kernel mailing lists (for new patches) and I see no evidence of HDMI support for the H616 or H618 chips existing. This means you will see boot screens due to framebuffer support in the kernel, but there's no HDMI (DRM) driver, so Kodi cannot run.

    If you add 'ssh' to boot params in extlinux.conf the SSH daemon is forced to start and you can login, but you'll only see kodi.log messages about there being no DRM surface or gem object to render to.

    Just report only, I don't make pull request for this.

    The current AIC8800 driver will not be accepted into our codebase. The driver code is poor quality and needs a ground-up rewrite and Radxa has no plan for that. We would be stuck with a bad out-of-tree driver. Our instruction will be for users to vote with their wallets and not-purchase any boards using that chip; unless WiFi is not a requirement.

    a) This is an English language forum. If you want to post in your own language; also provide an English version of text.

    b) We don't support Kodi on Windows; use the Kodi forum for that.

    c) We don't make recommendations on hardware we don't have/use - but LibreELEC is $0 so it costs you nothing to experiment and find out what works best for you.

    NAS setup would also depend if user wants to run network media server on libreelec or on nas.

    Nope, the NAS can be just a dumb storage device in the network. You can push the local media DB there too (MariaDB, etc.) if you have more than one client, but Kodi is not a true 'server' app that supports 'client' devices. If you want to run alternate non-Kodi server apps that's a different topic, but displacing Kodi wasn't in the original question.

    I would invest in a NAS box that sits in the network with a physical cable connection to the playback device. Then you can keep the current "does everything I need it to do" playback device; and in future change that device without storage features dictating the hardware options. The initial up-front expense is paid back over time in lower effort and cheaper future updates.

    The general advice for HDMI issues is to physically disconnect everything and leave powered off for 10-mins, then reconnect cables and see if anything fixed itself (as it often does).

    The getedid script solves a single and specific problem; the TV not being powered on before the RPi starts. That's the only issue it solves. It does not solve CEC problems. It does not solve any other HDMI problems. Do not use it, unless you have that issue.

    My understanding is that I just have to add this as package.mk to packages/linux-driver-addons and it will be picked up during make image?

    Not quite. Create the package folder and mt76 package.mk under packages/linux-drivers and test built the driver to ensure it compiles with e.g. PROJECT=Generic ARCH=x86_64 scripts/build mt76 then add the package to ADDITIONAL_PACKAGES in an appropriate 'options' file; either distro, project, or device level and the package will be built as part of a normal image build. Here's an example package.mk (for a realtek wifi driver): https://github.com/chewitt/LibreE…dd77d9cfa1d713e - no idea if that would work as-is or needs changes.

    The easier option would be to enable CONFIG_MT7925E=m in the kernel defconfig, as it's a one-line change and then you're using an upstream supported in-kernel driver. Just edit the relevant defconfig and rebuilt the image; the defconfig change will be detected and the kernel will be rebuilt automatically. NB: I've no idea if the driver needs firmware, but that can be manually added if needed, or you can edit the firmware pick file, either at project level or the x86_64 default one under the kernel-firmware package.