Posts by chewitt

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.

Kodi 17b4 has a bunch of issues so I'm not sure anyone will be looking at stack traces. Use 17b5, we already pushed commits to our branch for this if you're self building and next alpha (7.90.008) should be out shortly.

nVidia cards cannot output 23.976 correctly, it's normally something close, but never close enough for glitch free playback so you will see "pullup correction" to keep things in sync. The debug log shows this:

INFO: ID:0x1ce Name:1920x1080 Refresh:23.970909 Width:1920 Height:1080

The only way to resolve this is to use a custom /storage/.config/xorg.conf that details the exact mode timings for the screen, e.g. for my Samsung TV at home I am using this file: aTAB .. the key line is:

ModeLine "1920x1080_23.976" 74.1756 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

the 74.1756 value is a "tuned" version (4 decimal places) where normally it would be 74.17 (2 decimal places) and the extra resolution allows me to reach an actual refresh rate of:

INFO: ID:0x284 Name:1920x1080 Refresh:23.976080 Width:1920 Height:1080

Which is close enough that you only see the correction maybe once every 3+ hours, i.e. not during a normal movie. The fun part for you is figuring out the modelines for your TV, as they are TV specific and you can't just copy them from my file.

cp /etc/X11/xorg-radeon.conf /storage/.config/xorg.conf

then edit, and it will be used instead of the embedded (not editable) one on reboot.

VNC will do it, but this requires you to directly expose the box to the internet and VNC only offers basic password security as protection, so this is something we do not recommend.

I'm unable to see the issue, and this reply is sent from a laptop connected to the tethered AP created on an LE box (next Alpha release) so there is no underlying issue with connman. The only thing that might have changed from OE days is the wireless driver, but at that level in the stack the drivers are responsible for the AP feature working or not working (not even being possible) not some 50/50 state.

If you want a wireless bridge it's time to go buy some proper kit.

Although they may claim otherwise, the other user activated SSH during install which hardcodes it into syslinux.conf and this disables the normal on/off capability in the first-run wizard and settings add-on. From the next alpha build (7.90.008) the ability to force SSH has been removed as part of a general cleanup of the installer.

NB: If it is forced on, one reason for not being able to connect is an old (out of date) PuTTY version which is trying to use cipher suites that we no longer support in the SSL versions we use.

GitHub - LibreELEC/LibreELEC.tv: Just enough OS for KODI <= our collection of prior art

Add-on development is one of those things where the chances of success are proportional to the amount of help you need to ask for. The build system has a ton of existing packages. It's probably missing a few things needed for OpenHAB to work, but the structured format for a package is documented in packages/addons and that's really all the help we can offer - unless you have specific Q's about compiling/linking.

The lack of documentation is partly deliberate as it acts as a noise filter. My 5+ years experience with LE/OE shows developers who will succeed at the task might ask for a few pointers but existing content is all they need to create something. The developers who seek tutorials and how-to guides are missing the skills to succeed and usually end up asking us to write things for them, which we're not really staffed for.