Posts by chewitt

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.

1. Press the Home button of your TV remote.
2. Once you get to the home menu, select the cog icon (top right corner) to access the Settings menu.
3. Go to the Picture section > Aspect Ratio.
4. The following options are available: 16:9. Just Scan. Original. Full Wide. 4:3. 14:9.

^ copied from Google but ISTR my 65B7V was similar. Sometimes settings are input specific so even if you did this already for HDMI1 but are now using HDMI2 it might need to be repeated.

DEBUG: OnPlayMedia smb://192.168.0.101/Public/Video/Animation/Serie/Overlord/S03/[LostYears] Overlord III - 13 (WEB 720p x264 10-bit AAC) [05480D45].mkv

H.264 is an 8-bit video standard so nobody anywhere supports 10-bit hardware decode so it's CPU decoded. You need to distinguish between buffering which the advanced settings config you applied can help with and the stuttering problem you have which is all about how fast/slow the CPU is. You should probably get a heatsink for the RPi and apply some overclock to improve CPU performance.

If you want to watch 1080p H.264 10-bit media you'll be better off with an Intel NUC or similar which has a lot more CPU performance.

Set the SMB client settings in Kodi back to default (so it's using SMB2/SMB3) and configure the Windows end to share files to a local system user account with a username and password. Set the same username and password as the credential for Kodi to use. Network browsing will not work using SMB2+ so you must manually configure the source in Kodi. I personally find it easier to manually edit sources.xml instead of using the Kodi GUI to enter things via a remote control, and the XML format is simple, e.g.

        <source>
            <name>SHARE</name>
            <path pathversion="1">smb://username:password@SERVERS/SHARE/</path>
            <allowsharing>true</allowsharing>
        </source>

Also make sure any firewall (or endpoint security product) allows access - perhaps disable while doing the initial test.

My $0.02 suggestion would be to purchase a high-speed SD card and run LE from the SD card. On a fast SD card the performance difference isn't significant and spending some time to tune remote control timings (or using a better remote) will have a far bigger impact on how the GUI feels than the underlying storage medium.