Posts by chewitt

    Code
            <source>
                <name>MEDIA</name>
                <path pathversion="1">smb://user:pass@NAS/MEDIA/</path>
                <allowsharing>true</allowsharing>
            </source>

    I edit /storage/.kodi/userdata/sources.xml directly (not via the GUI) as I find it easier/faster than spelling stuff on a remote with no keyboard and the format is pretty simple to follow ^

    If you're sharing from a machine that uses DHCP make sure you use the hostname (NAS in the example above) else the DB will break when the host changes IP address.

    The reason the TB image is not listed in the USB/SD Creator app is we need to modify the app to not crash when RK images with suffixes are listed in the JSON data. Fixing that is somewhere on our to-do list, but not yet at the top of the list.

    NB: All of our RK images are currently in a persistent 'alpha' state while we finish reworking the codebase around the mainline kernel .. the alpha's use the older RK 4.4 kernel. That work is approaching the point where we can switch and then start the journey towards LE10 which is when things should be officially official.

    Sorry I missed that. We have an (unsupported) OVA for vmware that we use for development work but Virtual PC, VirtualBox, Parallels, HyperV, KVM etc. all require drivers that we don't have in the distro images. There's no plan to change that.

    rgmii (10/100/1000) and rmii (10/100) are different realtek PHY drivers .. the PHY is responsible for the physical connection to the network and Amlogic chips support "internal" rmii for free (it's part of the core SoC). Cost-engineered devices often skip the optional "external" PHY chip (usually rgmii but there are other options) to shave cents on the manufacturing costs. I'm not sure rmii is a good designation so the dts name might change, i've asked the kernel maintainers for their suggestions and preference.

    project: add cpumac package · chewitt/LibreELEC.tv@e01aba3 · GitHub

    ^ this is an (incomplete) experiment in solving the problem on mainline Amlogic kernels. It won't work exactly the same as the CPU serial number is not exposed the same way on legacy kernels, as but you should be able to tweak the cpumac-config script and change the system.d service to ExecStart the modified script from a /storage/ location to make something work. Once you stop the MAC address changing on each boot by overwriting with a known value, the IP address you set via static config (via connman, or DHCP reservation in the router) won't change.

    An OVA for vmware (workstation, player, vSphere) exists to support development work, but we have never formally supported it and have zero plans to change that or delve further into virtual hardware usage (KVM etc.) as it's very niche. YMMV.

    Kodi v17 and v18 are different with different features. Settings that exist in both will "migrate" to the newer version. Settings that never existed before the new version will need to be set. This has been true of all Kodi releases since I've run in the last decade. In most cases add-ons should self-update on first run of the newer version, but there may be reasons why that didn't happen and resulted in things being disabled. The main reasons are that you have old versions of Kodi binary add-ons are installed that are no longer API compatible and nothing newer is available. If all the add-ons were disabled you had a corrupted add-on DB leading to migration failure. In this case the problem add-on DB is cleared and automatically regenerated, but all the add-ons are disabled to prevent issues.

    This thread is for balbes150 testing LE releases which are now focussed on the mainline kernel. If you want to run CE releases and discuss CE topics please take the chatter to their forum. If you want to experiment with mainline kernel images and LE things feel free to hang around here.

    I've boot tested a C2 running the AMLGX (mainline kernel) image and from tonight or whenever the next balbes150 image gets pushed the HK remote works OOTB including power on/off (i've added device-tree keymap configuration and a kernel driver for the HK remote this morning). I have no idea about Harmony compatibility but it's a standard NEC protocol device so it probably isn't a big challenge for a learning remote.