The lack of info in kodi.log proves Kodi didn't do/signal anything so the issue is either something in the Linux kernel/DRM layer or perhaps (as suggested) something related to the TV itself.
Is there anything in the system log (dmesg)?
Posts by chewitt
-
-
Manufacturers who make hardware constantly add features to "improve" output, both to improve the viewing experience, but also to ensure the marketing department has something to support claims of their device giving the best experience. Some viewers claim these features do improve their experience and <insert_name_of_latest_device> is the best thing invented since sliced bread. Others seek to watch movies "as the director intended" and claim the same features detract from the experience. Reddit provides a free service to fuel all sides of the "what device/distro/player-app/settings works best" debate by selling advertising placement to the marketing departments of manufacturers and retailers.
IMHO dedicated BR/DVD/SACD/CD hardware usually gives the best result. However my kids destroy BR/DVD disks by leaving them wrong-side-down on the floor and never place watched things in the correct box, so I still rip everything and accept the lossy format conversion to mitigate those problems. I use general purpose settings when ripping. I do occasionally re-rip with tweaked settings if the results aren't so great. I still choose to watch certain films on proper hardware sometimes. The amount of 4K/UHD media that I purchase and rip vs. stream from a subscription service (media reformatted to suit streaming and look okay on more devices) or record from a broadcast (media reformatted to squeeze into broadcast constraints) continues to decline though.
-
Two comments:
a) It's not unheard of for Android boxes to hard-code CPU identifiers in their software so that less scrupulous manufacturers can pass off older or cheaper SoC chips for something more expensive, or even chips from a completely different SoC vendor, if that helps to sell more boxes and/or clear stock. Hence you might find different SoC chips being reported in different places. The best way to check what's physically inside the box is to open it and literally see what's under the heatsink (if one is present). NB: Even that's not infallible, as we've also seen chips silk-screen reprinted to hide what they are, but that's not common.
b) There is currently a single LE image for an RK3328 based Android box, the "a1" image. If this works, great. If not, there are no plans to add more images for Android set-top boxes. As a general rule, trying to support them is a challenge. Boxes are typically based on reference designs so there is enough in-common to easily boot an image, but booting is no guarantee of reliability and there is enough variation in designs (combined with selection of cheap low-bin components) to ensure reliability always remains slightly beyond reach; whether that's due to electrical or thermal or other reasons.
-
It would be useful to see a Kodi debug log from one of the devices when trying to open the add-on.
-
Is maybe some memory/cache running out of space?!
Unlikely to be memory/cache related (and not a direction we'd look in). Please upload the whole file to Google drive and email a private link to chewitt@ our domain. I'll confirm Pi devs have it downloaded so you can delete the file/share after.
-
I've read on reddit that playing HDR content directly with LG native player produce better quality, how ?
Upstream Linux supports static formats like HDR and HDR10, not dynamic formats like HDR10+ and DV, so other player apps running on other OS e.g. Android with vendor kernel that includes magic closed-source binaries for DV support, or a good physical media Blu-ray player that similarly supports dynamic HDR types; should/could in theory give better results than e.g. LE running on an old NUC that does not.
Also what is the difference of using this NUC to play a 4K UHD BD Remux in HDR and using a good bluray player like panasonic UB820 with same UHD media but on physical disk ?
Some users will insist they can absolutely tell the difference and there is a multi-billion dollar industry designed to relieve them of $$ in the pursuit of "bit perfect" quality. That said, the entire concept of "bit-perfect" doesn't exist for video due to how original media encodes a suggestion of how to show things that is then interpreted by an imperfect display device, e.g. no TV in the market actually supports 10,000 nits brightness, so even if the source media is perfect the output that you see is always some kind of best-efforts compromise.
Ripping media to anything other than ISO results in format conversion and this is always a lossy process. Most users are happy with some quality loss for the convenience of having their media in a software format, and with HEVC and AV1 offering smaller filesizes than H264 and particularly ISO, for a "perceptually similar" level of quality, most users are happy to avoid the need for many TB of HDD space. I do find it amusing that the "bit-perfect" crowd found on Reddit and Android forums espouse on how perfect their system is when logs show their source media to be some remux torrent with totally unknown encoding.
Most users are just happy with the HDR logo lights up and the display and colours are brighter and things generally look better than a boring old SDR movie. Most users over the age of 40-years are also subject to some level of macular degeneration.
"Don't believe everything you read on the Internet" -- Abraham Lincoln
-
The [email protected] issue is seen with pass-through audio; thus Kodi cannot resample the audio stream else you defeat the entire point of passing-through the untouched audio stream to the next device in the HDMI chain.
The correct behaviour is to reduce the video bit-depth from 12-bit to 10-bit so there is enough bandwidth for audio. Intel devs will desire this to be dynamic so the driver maximises bit-depth unless it needs to step quality down. This is more for desktop distros where the bit-depth quality of the desktop is viewed as important. It's less of a concern for LE as no broadcast media uses 12-bit depth; only some Animé content with special (non-standard) encoding so we're fine with 10-bit max. If the Intel devs come up with usable patches (or at least show serious signs of upstreaming a proper solution) I'll be prepared to accept a temporary hack patch that caps the driver at 10-bit. If there's no sign of being able to drop the patch in the future, that's not an option.
-
the following command doesn't work: ssh [email protected]
-
-
The response to the latest post I made to the Intel bug tracker thread was positive and shows people are a) still employed and doing driver development work, b) now accepting the strong correlation between bit-depth and bandwidth consumption being a big hint on the problem. Hopefully the patches they've linked in the thread get cleaned-up 'soon' so we can test them.
-
If you write LE13 on the eMMC, it is not guaranteed that you will be able to boot older versions.
The Amlogic vendor kernel has some drivers that assume an era-appropriate vendor u-boot is installed so it can probably be done with a little manual fiddling (which there are no guides for) to fix wrong-named boot files, but I guarantee that some drivers don't work right, and as the maintainer of the AMLGX image; this is not something we have any interest in trying to support.
-
Well done developers, I really like what you have done.
Credit is more likely due to Tvheadend devs or Kodi pvr.hts devs. All we do is bump the add-on as updates are pushed
-
No fix yet, although it looks like Intel devs have finally grasped/believed the problem after we posted a recent update to the bug report on their tracker, so maybe we have some test patches to play with in the near future.
-
Code
2026-01-25 21:12:52.489 T:1107 error <general>: ffmpeg[0x3700b3f0]: [hevc] frame_post_process: Decode fail 2026-01-25 21:13:40.973 T:1129 error <general>: ffmpeg[0x3706d650]: [hevc] frame_post_process: Decode failThe file is "Irgendwie Schwanger (2025).mkv" ? .. If yes, this ^ is recorded in the logs (two different plays of the file). You'd need to enable ffmpeg debugging in Kodi logging settings to perhaps see more info about the media stream - that might show if there are other issues or oddities in the file, e.g. from bad encoding.
If you have a spare SD card, test the same file with an LE13 nightly and see if that makes a difference?
-
But i can't edit it with an editor. When i just open and save it back, the file gets bigger and booting from sdcard doesnt work anymore.
It's a compiled binary file (albeit one with lots of readable strings inside) so when you 'edit' the file you break it, and because boot depends on this file, boot from SD is broken. Like all compiled code, the source file can be edited, then it needs to be recompiled when you create the image.
-
sky42 maintains an LE image for x86_64 devices that includes support for encrypted drives (our default image intentionally does not support this). The drive needs to have a Linux filesystem, e.g. EXT4 and be locally mounted. You can then share the drive over SMB if desired but as it's already locally mounted there's no value (only pain) in trying to locally mount the drive a second time as a remote SMB share.
Have a read of his thread LE 12 added lvm2, luks (dm-crypt, veracrypt, bitlocker), mdraid, ext4 encryption
-
It looks like groundwork for USB support is here: https://patchwork.kernel.org/project/linux-…[email protected]/ and that series has been merged for Linux 6.19.y which we will bump LE13 nightlies too in the next month (once it ships) but looking at https://github.com/morrownr/rtw89 quickly I don't see obvious patches for RTW8922AU that could be simply picked on-top to add support, but if that codebase works then I'd be reasonably confident of support coming in the next couple of kernel cycles as the developers working there are quite active and constantly chipping away at upstreaming.
For the rtw88 driver we intentionally disabled the incomplete in-kernel driver in favour of using the lwfinger/rtw88 dev branches for a while, but that allowed us to drop older Realtek vendor drivers at the same time, so the additional hassle of regular bumps to keep track of development was acceptable. I'm not sure we want to repeat that for rtw89, but if you can build an LE images and look at git history to see how rtw88 was handled it shouldn't be too hard to add support.
-
IIRC the WeTek Play/Play2/Hub boot mode is toggled between WeOS and LibreELEC on SD card by pressing the power or pause (can't remember which) key on the remote while the WeTek splash screen shows. The boot choice is then remembered until you either remove the SD card and it will default back to WeOS/Android or you repeat the remote-key toggle. Using this original boot flow it will not auto-boot into LE simply by inserting the SD card. If you boot CE or the dtech image using the typical "toothpick" boot method the boot flow will be modified to boot on presence of SD card, but the LE 9.0 image will not do this as the autoscript files on the SD card do not have the instructions to modify the boot flow.
TL/DR; the issue was "PEBKAC" due to incorrect assumptions (based on some other distro) on how things work.
