Posts by chewitt

This was merged/included in the v7.90.008 build.

The skin you're using is Estuary not Confluence, and it will be a remote key mapping issue, which means you (our users) can make experimental keymap changes and then tell us what needs to be changed.

There are no plans to confuse people with multiple boot methods as RPi3 hardware does not support the feature without updates first, and we prefer to avoid 5000+ "flashed a USB stick and it doesn't work" forum posts. At some future point when RPi4 comes along with USB-boot support from the start we'll entertain the idea.

Running "find / -name remote.conf" will find it in OE, if it exists. Any OE build for thoses boxes is likely to be a custom build with it embedded rather than something user-configured.

SSH in an run "parted -l | paste" and share the URL it generates; -l is lowercase L

I've posted v7.90.008 builds to Index of /slice/ for testing (manual update only at the moment). There appears to be an issue with S/PDIF 5.1 output on CM3 boards but Gordon is aware and investigating (optical 2.0 output is fine). I'm also going to look at adding the lirc disable function one night this week as having one remote driving two boxes is becoming annoying.

btw, the sound card change went into v7.90.008 which was released yesterday.

Nope. I'll comment on differences but as a point of principle I never make specific product recommendations.

There will be a 7.0.3 release to add an enhancement to the settings add-on that will ease migration to 8.0.0, but at this stage of development the "if it works, don't fix it" rule applies so there is no plan to make other changes. Adding a large chunk of DVB drivers that few people will use is not going to happen.

The .tar file is in the direct link you were given in post #2

If you're using community builds on what looks like 3.10 kernel this is an Amlogic device? .. so first port of call is the build creator, or whoever's upstream development branch you are self-building from. Follow their advice on the bug and where to report.

Google for LE community builds from @piotsrad, he's the unofficial Cherrytrail champion on the team

As things stand today Xorg starts and creates a modepool based on the EDID presentation from the TV and this is fed to Kodi which builds its internal reference of modes ONCE at startup. Then you switch the device in the AVR to the projector which will result in a different presentation to Xorg which probably adjusts to the changes (maybe) but Kodi will not see this unless you stop/restart the Kodi service.

In some cases the switching it might work because the modes supported by TV/projector are similar enough you get away with it. In other cases there's a mismatch and you see odd things. At the end of the day the LE/Xorg/Kodi combination is intended to be used with a single HDMI source that doesn't change after startup so deviating from that will give mixed results. I suspect you'll be better off fixing the NUC to use hardcoded EDID from the AVR so Xorg/Kodi is not trying to handle changes, then letting the AVR handling further conversions.

NB: I have memory of an issue with EDID and some Pioneer AVRs going back a couple of years (Google for OE "Pioneer Edition" builds) but I forget the details and have no idea if that's at all relevant/related to your issues.

If the app is the problem a Kodi debug log might show the last action before something restarting and this should be renamed to kodi.old.log at next restart. If the OS is the problem the systemd journal might reveal something. However, the nature of issues that cause hard resets is there's often few clues left behind and it will need some technical trial and error to figure out things that influence the behaviour.

Nobody at Intel marketing loves me enough to send NUC test samples so I don't have one. However with other boxes I mostly use anything MCE compatible that looks like it will survive two energetic kids for a while (more of a throw test than drop test) and doesn't have an unusual or weird button layout (WeTek Play 2 fails here). On any given day there's a choice of 4-5 different boxes/remotes available and they're proving to be quite adaptable in figuring them out

This is a bug in Kodi v17b4 that is fixed in v17b5, so wait for the next nightly and update/try-again.

NZ$180 = US$120 which pretty much equates to the US$100 image shown + suggested value of a decent PSU; so you're all talking about the same numbers just in different currencies

NUC's are great (although not cheap) but 10b HEVC is becoming the norm so I'd want to wait for small form-factor Kabylake devices to start shipping in the next couple of months. I don't have experience with the C2 but the similar S905 Hub/Play2 WeTek boxes I have for testing perform well against everything in my media library running current Krypton alpha builds. There are still some outstanding quirks to fix but there are a lot of clever people who want those boxes to work great. The only complaint I have on either WeTek device is the sub-par remotes (lots of feedback from LE/Kodi devs to WeTeK on that).

ply-image /path/to/splash/image.png > /dev/null 2>&1

that might work (if it doesn't, there are no other ideas) but I'd experiment and reduce the sleep value instead of doing this.