Start with a current Milhouse development build as this has a much newer Linux kernel and the mmc driver initialisation problem (-110 is just a generic error code, it's not so helpful) may have been resolved in more recent kernels.
Posts by chewitt
-
-
There is a VNC server addon for LE allowing you to connect from PC to HTPC, but nothing exists that allows connecting from HTPC to PC.
-
What hardware do you have?
-
is there any reason why these quirks are not already upstream and included in kernel sources? - e.g. patches being submitted and rejected by kernel maintainers?
-
There are niche but known issues in the Pi firmware used in 8.2.5 but current milhouse releases will have newer firmware that resolves some of them. Update and retest, then if issues are still present, post in the milhouse support thread in the Kodi forum to ensure the issues are flagged to Pi foundation staff for further diagnosis.
-
The bootlin branches are now some way behind current LE and current Kodi so additional work is needed over the next few weeks to adapt some of the changes so there's a common approach over other SoC types. Then we can get things merged into Kodi and look into some of the other distro packaging challenges. Allwinner "support" is still some way off, but it's been really positive to see things progress and our long-term vision for a unified zero-copy video pipeline taking shape.
-
No ETA. The amount of remaining work to switch GXBB/GXL hardware up to mainline with an HDMI 1.4 featureset is small, but also dependent upon a limited number of developers who have a huge paid-job workload, so pro-bono work progress is frustratingly slow. There is still no clear mainline path for GXL devices for various currently insurmountable technical reasons (drivers, etc.)
-
In the last couple of weeks the SFTP feature was removed from the main Kodi codebase. It can now be (re)installed as a binary add-on (vfs.sftp) but LE hasn't added it to our build-system so it's not in our repo. That will probably happen at some point, but I wouldn't promise when.
-
I already did.
-
I haven't been able to get my Digi+ working in Openelec after following your instructions, any ideas or tips?
If you install OpenELEC (a long-dead project) your problem is not our problem. If you install the BerryBoot "LibreELEC" image you are not running proper LibreELEC and your problem is not our problem. Install LibreELEC natively (so the running kernel is our kernel) and we'll provide support.
-
The scrolling text is probably kernel log output so the device is trying to boot something, but that's not a supported device so whatever image you found will have an incorrect device tree, which leads to random problems. Device tree files are device and kernel specific.
-
LE in default configuration does not provide an audio sink for BT devices like Google Home to send audio "to" although since it's a BT device you can pair things. It is possible to reconfigure pulseaudio in the OS to provide the required audio sink, but then Kodi (which uses alsa unless using pulseaudio to stream audio over BT to an external speaker) will be unable to output audio via alsa over S/PDIF to the AVR/Soundbar device when playing movies etc.
-
There are no official Linux drivers for RTL8811CU devices and the couple of user-created efforts that show up on GitHub look a bit too home-grown and we wouldn't consider adding them to the distro (we have enough problems with the crap code in the official ones).
Send it back and find something that uses the ath9k driver.
-
You haven't stated the LE version, but if you're using LE 8.2.x the results are as expected and you need to test again with a current master branch (e.g. Milhouse) release which contains drivers and Kodi with basic HDR support (emphasis on basic as Intel drivers are still "work in progress" on the HDR topic).
-
It might sound like a weird question, but what colour (or manufacturer) are the problem eMMC modules?
-
-
Update to a current Milhouse alpha release of Kodi v18 and retest. There are many improvements for 4k support. Then you're also running a release that is under development and can receive fixes if something isn't already resolved.
-
It's an infrequent and half-understood issue with the half-fixed audio subsystem in ye olde 3.14 kernel. It will not be fixed, because nobody with the competencies to perform major kernel development is prepared to work on that fugly codebase now. The 'fix' will come when we flush that turd kernel and move up to mainline, which is something being actively worked on.