No debug log or factual/technical information to investigate from = Not our problem.
Posts by chewitt
-
-
Sorry, our crystal ball is broken. In the absence of any factual detail we will not be investigating anything further.
-
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository

17:49:08 T:3035529792 NOTICE: ADDONS: Using repository
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository repository.ytplugin
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository plugin.video.ZemTV-shani
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository repository.whitecream
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository script.video.F4mProxy
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository plugin.video.f4mTester
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository
17:49:08 T:3035529792 NOTICE: ADDONS: Using repository
Official:Forum rules/Banned add-ons - Official Kodi Wiki
No further support.
-
Official:Forum rules/Banned add-ons - Official Kodi Wiki
It's always a sunny day when repo's that are full of pirate sh1tware fail to install. -
It's the same keymap as 7.0 but Kodi changed/renamed some stuff and so the keymap needs to be adjusted. If you wait for us to do every tiny detail we'll get there, but fiddling with a keymap is currently low on the to-do list. So this is where our users can help, or not.
-
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.
-
-
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.