Posts by chewitt

The connection manager (connman) service manages the functionality of the hotspot and aside from the options I mentioned above all behaviour is internal and hard-coded. There is no config file hidden somewhere that you can tweak.

As a broad rule NUC's are plentiful in number so issues are seen early in testing so we're not aware of any major issues. Current OE and LE releases should be using the same kernel series and driver/firmwares so will be broadly the same. Older OE and current LE will have larger differences. I'd start by making sure all have the latest BIOS/firmware available as that's what the newer drivers etc. are developed against. Then if that didn't cure anything run "dmesg | paste" and share URLs so we can see boot processes and look for error messages.

I'd guess the SATA controller hardware isn't supported, which is either simple or horribly complicated to resolve (in software) depending on what chipsets are involved. Run "dmesg | paste" and "lscpi | paste" from the console and share the URL(s) please.

Then cross fingers and hope there are no undiscovered vulnerabilities in the TVH webserver that has been exposed to the Internet. I'd advocate using a private VPN to securely access the home network, then navigate (as normal) to the TVH device.

Please run "lsusb | paste" and "dmesg | paste" and share the URL's generated so we can see what chipset is in the DAC or how it identifies with the kernel during boot. Then we can see what's required to support it.

read Pulseaudio - LibreELEC

It will not give you complete instructions on how to configure dual-audio, but with some fiddling about you can probably do dual-streaming. It will just require some different pulse modules to be loaded first.

It is not possible to edit content in /etc because the filesystem is read-only.

Not possible. ON/OFF, SSID and password are the only config options. It is functionally the same as the hotspot on your phone.

The only thing you could try is connecting the other way.. i.e. tether LE device to phone hotspot. As long as the remote app and box are in the same IP subnet they should be able to talk.

Looks about right. You cannot harm/bork anything from experimenting

Random thought: Are the back-ups you're restoring from an "XBMC" install, or from a "KODI" install? .. because files backed-up from /storage/.xbmc will be restored to /storage/.xbmc and these days Kodi expects to find everything /storage/.kodi which would result in no new (old) files needing to be migrated and you'll see the box just start-up into Kodi, which is what you originally described.

I can see some old cruft from OpenELEC is present in the config. Perhaps create a backup, update to 8.0.2 then reset the config and do a clean start on the box. Manually restore some essentials. Spring cleaning often works.

Install the RPi Tools add-on and you have RPi.GPIO and gpiozero to play with. Google them for more details.

It's not the normal behaviour. Most odd things that happen after upgrades tend to be add-on related. Things that keep track of what you watch etc. would be my guess. Post a Kodi debug log from clean boot where you play something to demonstrate the problem. Use the built-in paste function in LE settings and share the URL or use pastebin.

Use the EZ-Setup from here MrChromebox.tech and it will handle BIOS/firmware changes and installation of the latest LibreELEC version that runs on Chromebook devices (the Generic image). This is the officially unofficial way to handle Chromebook hardware

Soli was the inspiration behind some of the changes in the 6.0.1 image and i'm happy to see someone pick up the baton. These days I simply don't have time to spend hours fiddling with ancient boxes. I also find the difference between an Amlogic S905 or RK3288 box costing $30-40 and ATV1 is too great, and once you hit that mental wall and move on it's hard to retrace your steps.

Pimoroni have shipped a replacement Slice PCB and PSU to my parents who will pass it on when we meet-up in Spain in a couple of weeks. As long as the CM3 card still works I should be back in the Slice business for a public beta of 8.2 in July and release in August.

Meanwhile lrusak is in the process of re-packaging the Slice drivers/firmware into packages we can embed into the Slice image(s). This allows us to drop a bunch of Linux patches and the build-system difference between RPi and Slice is reduced to two words in a config file. This makes it basically impossible for me to miss patches again - future breakage in a release will require deliberate sabotage. He is also creating a python add-on that hooks into Kodi to drive the LED ring. This allows us to drop the Slice Kodi patches and in the long-term we can make the LED patterns for Kodi actions user-configurable.

Kodi has a deep integration and dependency on ffmpeg so basically the answer is no.

Unless you tell us what WLAN chipset is in the box nobody can tell you whether the WLAN device is supported (or not) or what may be required to make it work. Saying "MXQ" box is like saying "I have a blue car" .. it tells us nothing.

First post is updated.

option "CustomEDID" is an nVidia-only configuration parameter so I'm not surprised Intel drivers don't like it, although segfaulting sounds like bad code design for error handling. That's not the issue though. Remove the custom xorg.conf and re-run the getedid script.