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.

    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.

    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 :)

    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.