The upstream hardware decoders aren't perfect but much depends on the source media. Some users have collections that will fail miserably. Others will find it's surprisingly usable. You'll need to experiment with a spare SD card or eMMC module.
Posts by chewitt
-
-
Hello, any suggestions how to prevent corruption when the power fails?
Disabling the write cache helps. Mounting read-only helps. Using EXT4 or perhaps BTRFS (with more advanced journaling) instead of NTFS also probably helps. Using hardware RAID helps. We do not support software RAID; there are too many variants and tools and we prefer to avoid the bloat incurred. No filesystem is corruption proof so if you truly want to prevent corruption, prevent the loss of power (Yes, get a UPS).
-
If you all "know better" .. https://github.com/xbmc/xbmc is eagerly awaiting your contribution

-
You're welcome to test, but I suggest stopping Kodi and copying /storage/.kodi to /storage/.kodi-backup first so you can revert back to LE12.2 in case of any issues; Kodi does not support downgrades so upgrading to LE13 nightlies is a one-way process. It's best to pick a nightly image as I haven't built images for older boards for a while; my testing focus is on newer ones.
-
The ability to turn on from CEC probably requires support in (mainline) u-boot and for the device to be in a suspended state so there's some level of power to detect things on the HDMI connection. I've no idea if that's implemented or not. I'll ask the main Amlogic u-boot custodian, but an answer might take a while as I know he's currently on vacation.
-
PLS, HEAD DEVS OF LIBREELEC/KODI. THINK ABOUT MY IDEA!!!
Your idea requires all media to be adapted to a different refresh rate. This requires excessive CPU resources. The idea also breaks the concept of a zero-copy video pipeline which something that Kodi has long-worked to implement because it's the most efficient way to process high-bitrate and large filesize media. In short; the idea is a load of hooey and dead in the water

-
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.
-
Read (it's not only about 4K/HDR) https://wiki.libreelec.tv/configuration/4k-hdr
-
Google searching shows absolutely zero technical information about the device or the chipset(s) inside it (the details that matter most) so it's not going to be supported on Linux, and media_build is not going to magically change that.
-
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 not seeing anything in Armbian patches.
-
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.
-
OP did not tell, if they are using Jellyfin or Homerun
Jellyfin does not support transcoding on the Amlogic hardware used in the current box and the OP is asking about an alternative to that box with local storage. So "being able to transcode using Jellyfin on the NAS" is not really part of the requirement, is it?