Posts by chewitt

    Code
    systemctl stop kodi.service
    mv /storage/.kodi /storage/.kodi-old
    systemctl start kodi.service

    ^ You can stop Kodi and move items like Thumbnails, sources.xml and library DB files from the old folder to the new folder and restart. No need to wipe the drive. I forget what all the version numbers are for DB files so start Jarvis once with no config and it will create them, then you know which file versions to copy back.

    The device you're using is irrelevant. If you downgrade back to Jarvis some things like libraries will revert to previous state because you resume using the older DB files that are still kicking around in the filesystem, but you now have a hybrid Jarvis/Krypton guisettings.xml file and some of the add-ons installed will have been updated to Krypton-specific versions that either won't work or might not play nice with Jarvis. I'd advocate copying the library DB files and thumbs somewhere safe then starting over with a clean Kodi configuration before moving sources.xml and DB/thumbs back.

    Next time make a backup before you start, then reverting cleanly to Jarvis or a previous state is trivial.

    Not possible. There is activity within the team towards Rockchip support in Kodi Leia (which is months away) but this work is focussed on current generation SoC's like RK3328 that have reasonable (and still improving) mainline Linux kernel and driver support. The new generation devices have become cheap it makes no sense to spend time/effort on older chipsets requiring non-standard Android kernels that contain too much low quality code and bugs.

    Code
    wget http://sprunge.us/MRPN -O /storage/.config/gpioshutdown
    chmod +x /storage/.config/gpioshutdown
    wget http://sprunge.us/MgBZ -O /storage/.config/system.d/powerbutton.service
    systemctl enable powerbutton.service

    ^ The first URL has a slightly cleaned-up version of their gpioshutdown script. The second URL has a complete guess at a systemd.service that runs before Kodi startup. I am a novice at systemd things so no guarantees it will work. I also have no clue what other GPIO dependencies are required for the gpioshutdown script to work. You should consider them as a hint at how to do things; they are likely not a complete solution.

    S905D are the chips to watch for (devices with them should start to appear soon) as they have the same spec as S905X but with GB Ethernet. There is no HDR support in Linux at the current time but the first patches for HDR support on Intel GPU's were submitted to the Linux kernel last week so that will change in the future. Once things are in-kernel Kodi can start to evolve support. Once Amlogic completes work on a mainline kernel (not the ancient crap we are using today) support can be added there too. Android is a completely different discussion and I'm honestly not aware how good/bad things are there. It's usually a hack-fest of bad though.

    The most common reason for shutdown problems are background services installed via add-ons that take a long time to shutdown after receiving an instruction to stop, so Kodi reaches a timeout value and has its process killed before guisettings.xml has been fully written. The incomplete xml file is then detected at startup so Kodi substitutes a clean (default) file without the settings you've made. The most common problem things that I've seen delaying shutdown are large docker containers, torrent client add-ons, and some of the torrent based pirate streaming crapware. There is no general LibreELEC shutdown issue on NUC devices else the post count in forums would be notable (they are popular hardware) so it is likely to be something local to your install.

    Solve the reason for guisettings.xml and things aren't an issue. I'd also look at hardcoding an edid.bin file (run getedid from the console) as this will negate handshaking issues if they also contribute to weirdness.

    In the past I'd say "whatever works for you works for us" when it comes to LE/OE choices, but the longer OE continues to fester without security updates and bad design choices, that statement becomes ever-harder to make.

    Please have another go at submitting the packages to our github repo. It's hard to see exactly what the mistake was in the previous attempt but i'd guess you did changes in a local copy of the 8.0 branch and then submitted the PR to our master branch. This will include all the changes between 8.0 and master (350+ commits) in addition to your changes, which get lost in the noise.

    First clone our repo to your personal GH account using the GH web interface. Now clone (download) your repo to wherever you're going to make the changes. Checkout a new "topic" branch from master for the changes. Make changes. Push the local topic branch to your GH repo. Then PR from the topic branch in your GH repo to the master branch in our GH repo using the web interface.

    The rookie mistake (and we've all done it, everyone is a git noob at first) is cloning from our repo and making changes in the master branch. It works for something you build locally but it becomes almost impossible to upstream/contribute a clean PR.

    Code
    wget http://chewitt.libreelec.tv/xorg.dri3 -O /storage/.config/xorg.conf && reboot

    Run ^ that command against an 8.0.2 install and see what happens. It installs a custom xorg.conf that forces DRI3. It does remind me of some older Intel GPUs that don't play nice with DRI2 vs. DRI3.

    It sounds like you enabled "disable password auth" in the SSH section of LE settings. This won't disable the login prompt but will prevent the default root/libreelec password combo from being used (only SSH key-auth works).