udev rules are cummulative so you can add a rule to /storage/.config/udev.rules.d/ that matches on label/uuid and runs fsck on the drive. This will then be a persistent behaviour that is done on each boot.
I'm not sure what the match criterial look like in a rule so you'll need to Google a bit, but the following commit shows a similar rule that matches on HFS+ filesystems and fsck's them so the rest of the rule will look similar:
I didn't look (and have no plan to either) but I doubt it's wildly different. Despite all manufacturers claiming their product is unique it's in their own interests (for software support) to not diverge far from the reference designs.
s/branch/kernel ..
Use the default AM8-AUDIO? device which outputs on HDMI and S/PDIF at the same time - and don't necro-bump old posts.
I haven't built 3.14 branch for some time, but you need a version of this commit for whatever libmali is being used:
add support for EGL_KHR_debug · chewitt/libmali@9143da0 · GitHub
There are paid-for solutions to mounting EXT4 partitions under Windows but it's not worth the effort.
Copy the tar file to the new device and learn how to unpack a tar file from the SSH console. As the saying goes .. it's not rocket sc1ence.
Assuming you pass the "understanding the build system" test and can create a working "Generic" image the main issue you'll have with older hardware is GPU drivers. We tend to support current and recent hardware not old hardware; if we still have the drivers it'll work. If not.. more creativity in the build-system is required.
Linux SBC's are pickier with USB/SD when they run shitty/ancient kernels. Run a modern kernel and those issues generally go away.
No .. contact the manufacturer. And don't double-post the same irrelevant question.
If you have more than one output and the BIOS supports display mirroring then it can work; Kodi still outputs to one screen but the underlying hardware will send that one output to both. I doubt NUC's do that though - it's normally a laptop feature.
^ that's a good start to the year, although these things usually take a few iterations before being accepted.
If all you plan to do is overwrite stuff .. why make the process complicated by manually unpacking the tarball on a Windows box. Just use the restore function in the settings add-on.
Kodi supports output to ONE screen so it applies to whatever that one active output is.
Remove the autostart.sh script and clean boot, then run "journalctl -b 0 --no-pager | paste" after startup and share the URL.
Update to the current Beta and you can set the resolution to 1080p while whitelisting 4K modes so they can be switched-to for 4K playback if needed.
Almost certainly Kodi, and should be reported to their developers via their forums (with appropriate debug logs/evidence).
OE dropped support for i386 images after v5.0 and LE numbering starts at v7.0 so there has never been an LE release that supports i386 hardware. That said, almost all of our build-system supports 32-bit compile (as all the Raspberry Pi stuff is 32-bit) so if you're familiar with the build-system it's not too hard to effectively revert the commits that removed support and create i386 images and binary add-ons. To add perspective; older x86 hardware that needs a 32-bit image probably runs Kodi 18 worse than a Raspberry Pi Zero costing $7 so the question is always "is it worth the effort" ?
