Posts by chewitt

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.

Quote from blanco12

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?

Shield = Android = Someone else's problem. AFAIK none of the staff possess or use one, so we're not the right people to comment.

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.

It's booting the kernel but the init script is not able to mount the squashfs SYSTEM file from the /flash (boot) partition. The normal reason is the filesystem being marked 'dirty' and it needs cleaning to boot normally. The less normal reason is corruption to the SYSTEM file which could be an early indicator of issues with the underlying storage media, e.g. the good thing about LE is the entire OS is contained in two files, but the bad thing about LE is the entire OS is contained in two files; corrupt either file and the OS doesn't boot (whereas a normal distro spread over several thousand files is more tolerant towards single-file failures). USB boot a desktop OS like Ubuntu and fsck the filesystems. If that's not the issue try dumping the 512MB boot partition using dd as that will attempt to read the data areas where the SYSTEM file is stored. The other reason this error shows up is the partition labels not being set, but if the box was already working that's rather unlikely (although discovering new stupidity with NUC firmware stopped being a surprise a long time ago).

I'd go for the (s)lower grade of Crucial SSD's or whatever is on clearance sale because there is zero need for ultimate performance from fast SSD models on an HTPC box. Anything better than spinning rust is already awesome

LE uses connmand to manage network things, and connman supports configuration of DNS servers through dbus or the connmanctl local console interface which is scriptable but less sophisticated. Have a look at the LE settings addon for an example of a connman/dbus agent in python.

Correct, we don't build systemd with resolved support so it's not present. I guess the main reason is partly 'legacy' because when we first started to use systemd 'resolved' didn't exist, and since we have minimalist tendencies and the current arrangement works, there's never been a major reason to use/need it. I've always seen VPN services run up/down scripts, although that normally requires the VPN service conf to be modified to include those instructions. I'm not sure how you do connections, but I would always treat the user provided conf (or something from a known list) as a starting template that's copied to a working location and then parsed/modified to add features like up/down scripts before being 'executed' to start the connection.