Posts by chewitt

Sorry I wouldn't know .. I haven't run 3.14 kernel images for some time now.

If you do this (which is not recommended) please make sure you disable password authentication and use ssh key auth.

If not .. you'll be able to find yourself in Shodan within 24 hours.

The LE settings add-on is always visible under "Add-ons > Program Add-ons" from the Home Menu in any skin. The shortcut icon in the Kodi settings menu is only visible in Estuary and Confluence (and maybe Aeon).

Some wireless devices mount as a read-only CDROM (so Windows drivers can be installed) and they need to be modeswitched or the "CD" needs to be ejected before the actual NIC shows up. See what happens in dmesg if you "eject /dev/sr0" from the command line. If that works (and the NIC appears) it's an easy task to write a udev rule that does this automagically when the USB ID is seen. Some/most of devices that do this also have a Windows utility app that allows the initial CDROM mode to be permanently disabled.

It's one of those lurking corner cases that needs someone to rework scripts. It will be needed once more hardware moves to mainline kernels because the situation with broadcom firmware in mainline is both better (lots of unnecessarily complicated hciattach stuff has been eliminated by serdev) and worse (the kernel is still in the early stages of supporting hardware with the new regime). As a broad rule there is reasonable coverage of chips and firmware but zero coverage of nvram configs, so having the ability to experiment with those from userspace will be rather useful.

LE contains routines to fsck the boot partition if errors are found but I'm not sure those also include the /storage partition. NB: The solution to repeated power-off disk corruption issues is either a) stop pulling the power before you shutdown, or b) get a UPS to work around whatever terrible power situation you have going on. It's better to prevent the problem than wrongly assume the problem is always fixable - at some point you'll trash an important disk sector and lose the data. It's one of those "when, not if" scenarios.

The master location for hostname is /storage/.kodi/userdata/addon_data/service.libreelec.settings/oe_settings.xml .. but you'll only see the xml node for hostname if it has been manually added or changed via the GUI. Other services read the hostname from this location to set /etc/hostname (which is a symlink to /storage/.cache/hostname) at boot time.

<?xml version="1.0" ?>
<libreelec>
    <addon_config/>
    <settings>
        <system>
            <wizard_completed>True</wizard_completed>
            <hostname>WP2</hostname>
        </system>
        <connman>
            <wizard_completed>True</wizard_completed>
        </connman>
        <services>
            <wizard_completed>True</wizard_completed>
        </services>
        <about>
            <wizard_completed>True</wizard_completed>
        </about>
        <libreelec>
            <wizard_completed>True</wizard_completed>
        </libreelec>
    </settings>
</libreelec>

vpeter ISTR this won't work because the logic that appends things from /storage/.config/firmware to /usr/lib/firmware doesn't handle subdirectories and it needs to be located in /usr/lib/firmware/brcm/file or the driver can't find it.

In the future when Raspberry Pi transitions to the next-gen Kodi video pipeline (along with everything else we support) is when some feature differences might occur, but nothing has been done to remove 3D capabilities in K18 so they should be as-good as K17 (no better, no worse).

Quote from RDKL

Thanks for the suggestion but my problem is I have my box in a media cabinet so the IR wont reach it and an app will not have the ability to power it on & off.

I had the same "problem" which was solved by spending £15 on Amazon to get an IR extender box that sends any IR signals that point vaguely near a small receiver discreetly positioned on the outside of a media cabinet to the 5-6 devices that are hidden out of sight inside it. This works without fault and supports any IR devices and requires zero networking or configuration. Sometimes low-tech solutions are best.

np, glad it's sorted out

It's not the answer you're looking for, but our current RK codebase "is what it is" until the current rebase against a mainline kernel and changes to reimplement how RK uses ffmpeg (moving to a proper stateless V4L2 stack) has completed. And before you ask, there is no timeline or schedule for either of those

Two infrequent but persistent reasons I have seen for SSH services "not working" ..

a) The /storage partition is formatted as FAT or NTFS so it does not support unix permissions. In this scenario the OS applies 777 perms to everything on /storage and sshd considers private keys to be insecure so the daemon will not start. This should never happen with a default install as we create /storage as EXT4.

b) User has added extra wireless routers in their network and they are configured as routers so they create a second subnet (instead of using them as a bridge to extend the current subnet) so the wirelessly connected HTPC box is behind a NAT gateway and not contactable.

Have you whitelisted the resolutions that Kodi should use when doing "adjust refresh" ? If you haven't, everything will run at the deafult 1080p60 resolution, which isn't ideal on all hardware.

You're over thinking the issue (which doesn't exist). Put the card in the device and boot, and after first-boot the temporary 32MB partition will have been resized to the full capacity of the card.

I'm not sure what the issue is .. but we didn't change anything in the app for 12+ months so it's definitely something on the OS side that changed and is stopping it from working. Please use "Etcher" for now.

kivutar .. dive into Slack and we'll see if we can figure this out.

I'm not aware of the generation cut-off point for HDR support as "NUC" now covers eight generations of hardware that vary in capability, but I can confirm Intel needs to add HDR support to their video driver before the subset of NUC's that are capable can do it. The first submission of patches to the Linux kernel to start adding HDR support was only last week so it will be a while yet before things are usable.