Posts by chewitt

    Kodi v18 for iMX6 is in technical limbo. The older iMX6 interface in Kodi was broken for some time (more than six months) due to large surrounding changes in Kodi and nobody stepping forwards to maintain the code, which has been an issue for a couple of years. The irony is that iMX6 is maybe the most comprehensively documented SoC that exists for Linux, but anyone who has access to that documentation is under an NDA that prevents them from contributing their knowledge (gained from closed sources) to an open-source project. So right now we have a working OS image for iMX6 on a mainline kernel but the etnaviv DRM driver only supports a single output plane, which is not an impossible issue but affects performance (as drivers normally support four which allows GUI and video to be processed separately and combined before output which is more efficient). The DRM driver also doesn't handle mode switching properly so Kodi cannot change from 1080p60 to 1080p23.976 etc. and playback is not as smooth (and again, not as efficient) as it could be. There is allegedly some work going on upstream towards solving those, but we're a passenger in the process and right now there is nothing we can combine into something we can put our name to. I have a suspicion that iMX6 will skip a Kodi release, but might stage a comeback once upstream efforts on iMX8 have a trickle-down effect and improve things.

    It's possible to pop a simple toaster with simple one-line messages but anything more requires skin support for the Window format, which won't exist unless you tweak/hack the skin. However, the goal of a working systems is a) it just works, b) you watch movies not console output. If you fail on those criteria the configuration or something more serious requires code debugging and fixing, which requires proper tools, which means using SSH to see things, which means this is not required.

    For non-x86 devices it depends on uboot configuration. If the device uses the manufacturer provided uboot (which is the case in 99.99% of Amlogic boxes) it will not be possible as the console config is not required for Android so is missing from the uboot config. For SBC devices where we provide uboot (and in the future when running a mainline kernel where we can force CMDLINE options) it's possible to have a console same as Generic.

    P2P technologies (torrent etc.) are perfectly legal tools in 99.9% of the world legal systems, but the content that 99.9% of people use those legal tools to access would fall under our definition of piracy, and a hint of piracy will normally see us refuse support until a Kodi debug log (that proves the box is clean if piracy add-ons) is provided. You mentioned P2P streams and in the ~7 years that I have been involved with the project I still didn't witness a legitimate/non-piracy use of 'P2P' video streaming. It is not impossible that a legitimate service exists; merely improbable.

    If you want to use MythTV you'll need to provide your own MythTV server as we don't ship one. We do provide Tvheadend though; so clean reinstall the OS to the SD card (as it's quicker than clearing stuff out) and then add Tvheadend (server) from the "services" section of our add-on repo. Go to the web interface on your_box_ip:9981 and follow the basic setup wizard there. If tvh (not Kodi) can see the Hauppague hardware; drivers are good and then you'll get somewhere. If no hardware, use the driver select add-on to load the (not in-kernel) Hauppague drivers and rinse-repeat. Once you have TVH server configured and finding channels etc. you can go back to our repo and load the Tvheadend (client) from the Kodi PVR add-ons section. Kodi GUI loads the client at startup; which talks to the TVH server which runs in the background.

    So I hope you can see just part of the reason why I have removed this, you may think it is a bad or a poor decision on my part but I couldn't care less because I am fed up of the constant trouble it causes.

    GDPR-2 I'm pleased to see this direction as the wider team recognised it as a long-term support burden some time ago. One of our goals has always been "ease of use" and box installs are inherently more challenging than SBC devices due to multiple "how to make it boot an SD card" methods required - and adding the frequent complexities of internal installation on-top results in a range of box unique issues that tiring to repeatedly solve. It's true that an eMMC install is always going to be fastest, but team testing shows the performance of a good SD card reduces the gain to marginal levels unless the underlying box has inferior components (and crap hardware is always going to be crap hardware). An easier install process results in more people having a positive experience with LE, and thats something we care about more than appeasing the overall small (but increasing) percentage of users who purchase sub-$25 black box junk from far-east bulk buy websites. Caveat Emptor..

    I haven't looked deeply into HiSilicon requirements, but for anything vaguely official to go into LE's github repo (even as an experimental branch) the technical direction needs to be mainline kernel/uboot with DRM/GBM for rendering and a V4L2 (integrated with ffmpeg) driver to create a zero-copy (mem2mem) graphics pipeline. We have learned from our experiences of Amlogic and Rockchip. As long as those criteria are followed and/or there is a clear plan/vision on how to get there .. we're all ears.