Enable "Adjust refresh" and configure the whitelist for 1080@60/59.94/50/24/23.976 and 4K@60/59.94/50/30/29.97/25/24/23.976 and set the Kodi desktop to 1080p@60. Read https://wiki.libreelec.tv/configuration/4k-hdr
Posts by chewitt
-
-
"Team Kodi" is more accurately described as "small group of developers doing their own thing with occasionally overlapping interests" and as is common with non-commercial FOSS projects there is not much product management and no schedule. One of the few things its developers have ever consistently agreed upon is the need to reduce the complexity and improve maintainability of the codebase. That's the prime driver and motivation for the V4L2 long-term technical direction. Linux is inherently a fragmented ecosystem so we need to follow standards and be an advocate and agent-of-change for the establishment of those standards.
-
-
Single core, 1 go ram, x86, 32 bits model.
Our codebase dropped x86 support in 2015 back in OE 5.x days, so there are no LE releases that will run on it without a pile of detective work to figure out how to reinstate support and build a custom 32-bit image - it can be done, but it's not simple and there are no guides or willing staff volunteers for the quest - and as others have said, the Kodi experience once you finally get there isn't going to be great. An RPi kit will be much more rewarding for Kodi (suggested minimum RPi3B+ for 1080p or 2GB RPi4 for 4K and better experience) and also opens the door on the immense ecosystem of resources for other projects you can use an RPi board for.
-
It's a completely different codec so
-
At least 2 add-ons depend on this module, others might also depend on it.
How can this be best solved?
Flag the issue to the add-on author via their support thread in Kodi forums. Their code needs to stick to the default modules bundled with Kodi or they need to bundle the module (often as a supporting add-on) in order for Kodi to import and support it.
-
Are you guys on berryboot ?
LE has a long history of issues with BerryBoot which all originate in BB providing a different kernel build/config to what LE expects. Our advice is to avoid BB .. particularly if you want support from staff in these forums.
-
I deleted all Matrix images from my share 3-4 months ago when I switched to Nexus and renamed the thread. Even if you find a Matrix image it will perform worse and be less featured than the current Nexus images.
-
what can i do?
Share system log files?
-
do you see the vendor-specific ARM-based stuff as the 'future' of Kodi?
Team Kodi has been pursuing a "standards" based approach since 2016 and it's the reason Android now works very well. Linux is iinherently more complicated but a lot of the kernel frameworks are now in place and stable. Supporting older and current hardware has challenges as it means rework to existing codebases and commercial interests rarely fund work on old chips. However Google forcing Android device vendors to get ever-closer to upstream means future chip generations will increasingly have support written around the stable APIs and convergence will come. ARM devices are increasingly performant, and Intel stuff is still available (at a price) for anyone needing more.
-
Yes, but I only found this on chewitt testing site: LibreELEC-AMLGX.arm-10.85.0-odroid-n2.img.gz
This is a Nexus Kodi 20 Image.
I search for the same but Kodi 19.
I moved the nightly codebase to Nexus which is perfectly stable for experimental N2 images which have issues with hardware decode (except for H264 which works fine). so you would need to disable it and stick to 1080p media. There are no Matrix images for some time and no plans to go back and make any.
NB: I block PM because every self-entitled owner of a $20 Amlogic box seems to think I'm their personal support channel
-
Amlogic started upstreaming core board support to the mainline kernel, but it's a slow process so I wouldn't expect LE support anytime soon.
-
Found it emmctool but device not supported - any way to do force installation to nand?
There are no secret override switches/options and in my version of English "not supported" means it is not supported.
-
Could someone confirm the problem, at least?
63-character passwords are pointless. Anything over 20-characters is computationally infeasible to brute-force and a serious attempt to crack your network (if you're someone worth targetting) will either focus on a protocol or implementation flaw, or https://xkcd.com/538/
Regardless, it's a known issue and the workaround is to use connmanctl over SSH to join the network.
-
The x86_64 world is a little different to the ARM world. Intel/AMD standardised their hardware decoders around VAAPI so Kodi can call ffmpeg in a consistent way regardless of each, although at some point capabilities need to reflect which GPU/card and what the TV/panel supports. It all works reasonably well though advanced things like tonemapping still need to be plumbed in. Even nVidia finallly caved and added support for GBM/mesa to their latest drivers; and although Kodi does not support NVDEC (needed) someone wrote an NVDEC > VAAPI ship and we have a proof of concept implementation; although you need to run under Wayland which doesn't support fun stuff like "adjust-refresh" by design so it's not quite the solution nVidia users need (better than "no support" though)..
The ARM world is domainated by ARM Mali GPUs (well supported with FOSS drivers now) with separate vendor-specific decoders. These have a mix of "stateless" and "stateful" types under the V4L2 banner. The stateless V4L2 "requests" uAPI is stable and supports a good range of codecs upstream; it's still up to individual drivers to support them. The stateful "mem2mem" side is not declared stable yet, and with the dependency on vendor firmware blobs is generally a bit futher behind. There is a lot of collaboration happening on testing and upstreaming to the kernel - and LE is heavly involved in that (Kodi is a good test app).
On the userspace side most of the current activity on ffmpeg is focussed on making everything work. The process of usptreaming is looming on the horizon but it's still something to come. Again there's quite a bit of collaboration happening on this and we're involved.
Vulkan is an alternative to things like OpenGL/OpenGLES .. so "standards" .. https://xkcd.com/927/
-
LE has had millions of installations with the current .img format and MBR arrangement. It is not at fault. It all works when you boot LE as intended with the SD card inserted directly into the board. It stops working when you add your dual-card gadget. Ergo.. it's the dual-card gadget. I'm not sure what the issue is, but I'm out of ideas.
-
-
The "mini" version normally has S905W and SSV6051P inside, but that's assuming you get a box made by Tanix themselves and not one of the bazillion clones of their boxes