Posts by chewitt

  • LibreELEC on RPi4 messed up after repeated loss of electricity

    Code
    systemctl stop kodi
mv /storage/.kodi /storage/.kodi-old
mkdir -p /storage/.kodi
cp -R /mnt/oldcard/STORAGE/.kodi/userdata /storage/.kodi/
systemctl start kodi

    ^ that will deliberately not import add-ons (which will need to be updated) but does get all their settings and any other userdata config so anything you've configured should restart using the pre-existing configuration. Databases will be updated on first restart, assuming they aren't corrupted (which is a possibility). If a file is corrupted and Kodi hangs you can "tail -f /storage/.kodi/temp/kodi.log" and see which DB file things hang on, then stop kodi, delete the offending DB file and then restart Kodi again and if there's an older/earlier DB file it will attempt to import that one instead. Art content like thumbs is best left to download again as the resulting cache is smaller and more efficient.

  • HDD USB 3 spin-down. Over and over again

    Code
    ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/usr/sbin/hdparm -B 63 -S 36 /dev/%k"

    Put that ^ in /storage/.config/udev.rules.d/62-hdparm.rules and reboot to see if it improves things? NB: The -B value is power management aggressiveness between 0 (disabled) and 127 so we're setting it half-way, and the -S value is the power-down delay in multiples of 5 seconds, e.g. 36 = 5 mins.

  • HDMI disconnects as soon as Kodi loads

    I'd have a look for updated BIOS/firmware for the box, and perhaps think about running "getedid create" once the HDMI connection is up and working as this will force the kernel DRM subsystem to see the TV as connected all the time (even if it's not) which might help with HDMI stability (or it might not). I'd also think about trying other HDMI ports on the TV if it has some?. Also note that Kodi only outputs progressive so even if 1080i resolutions in EDID data they aren't usable. If you need to play interlaced material: enable adjust-refresh with the mode whitelist configured for 1080p @ 60/59.94/50/24/23.976 and enable refresh rate doubling so 25Hz material plays at 50Hz. With interlaced media this allows Kodi to render each interlaced half-frame in its own progressive single-frame.

  • LibreELEC support for Raspberry Pi 5

    Quote from HiassofT

    a manual "cross grade" on RPi4 (copy RPi5 tar/img.gz to the /storage/.update folder and also create a ".nocompat" file there, then reboot to install it) should work fine.

    Note that this ^ is a one-way upgrade as the RPi5 kernel that LE is using will not boot an RPi4. It's not impossible to recover from (mount and overwrite some files with the RPi4 image equivalents) but .. that's fiddly.

  • LibreELEC on RPi4 messed up after repeated loss of electricity

    It's hard to know what the issue is without seeing proper system or Kodi logs, but most likely something has gotten corrupted on the SD card. In that situation I'd recommend starting out with a clean install with LE11 (or an LE12 nightly) using a fresh SD card. This should get you back to a working (if not configured) system. From there you can connect the borked SD card using a USB > SD card adapter and see if the /storage partition on the card mounts to /mnt/<cardname>/storage or similar. If it does, restoring the general state of the previous setup is relatively simple and acheived by stopping Kodi, copying old userdata (database files, sources config and add-on settings) to the relevant location on the new card, starting Kodi up again, and (re)installing the add-ons that you were using. If you're familiar with some basic Linux fileystem and copy commands it's probably 5-10mins work to recover things. If you're not, it takes longer. If the old card fails to show up, then we need to see the system log to see what error messages are being generated. In that scenario it's probable that basic filesystem checks aren't going to get the card mounted and more complicated recovery processes might be required .. in which case "sorry, but now you understand the need for backups in the future!" is likely where we'll take a pause.

  • LE9.2 RPi kernel 64-bit?

    RPi4 on LE 9.2 has a 64-bit kernel and 32-bit userspace so that's not the problem or the solution. I'd suggest starting with an update to LE 11 or an LE 12 nightly to avoid all the issues found/fixed since the last LE 9.2 release (around two years ago).

  • [RPi3B+] Mounting pCloud Drive

    I'm not sure if that's an error about finding libpcloudcc_lib.so or libpcloudcc_lib.so is dynamically linked against other things which are missing and thus it fails to open the file which it found. There's no harm in experimenting with LD_LIBRARY_PATH so give it a try. You can also share the output from "ldd /storage/backup/libpcloudcc_lib.so" to see whether it's linked against anything missing.

  • RPi3B GPU accelerated H265 decode in LE 10 and future versions

    There are several reasons:

    a) Kodi no longer supports OMXplayer and MMAL decoding as part of the general move to drop all proprietary codecs to focus on modern kernel standards (GBM/V4L2).

    b) The Pi graphics pipeline in the newer kernel used by LE10 has been rewritten around modern kernel standards (GBM/V4L2) so "assisted" decoding would need to be reimplemented from scratch in both kernel and ffmpeg. The original patches amount to 100,000 lines of code and authoring that (and then maintaining is downstream) is a large effort.

    c) Only a couple of distros (mainly LE and OSMC) have been daft enough to allow 100,000 LOC patches into their codebases so the audience that would benefit from a large reimplementation effort in 'B' is small.

    d) RPi4 and up support hardware HEVC decoding (although to be clear, forcing hardware upgrades on users has never been a goal). It does mean over time the issues reduces in size along with the RPi2/3 user population.

    e) Nobody is forcing users to update from LE9.2 which continues to have the feature.

  • any chance to install LE to a partition instead of entire drive?

    Quote from django013

    May be its worth to give nvidia a hardware menu entry.

    Like this? https://libreelec.tv/downloads/generic/

    Wiuth old cards like a Quadro 400 (2011?) you'll need to compare the card PCI device ID with the nVidia udev rules to see if it's supported:

    LibreELEC.tv/packages/x11/driver/xf86-video-nvidia/udev.d/96-nvidia.rules at master · LibreELEC/LibreELEC.tv
    Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.
    github.com

    One of several challenges with nVidia support is that compat with Xorg is a moving target and eventually old(er) driver releases that are no longer actively maintined by nVidia require older Xorg versions than the current Xorg that we embed and things break. See:

    xf86-video-nvidia: update to 535.104.05 by heitbaum · Pull Request #8090 · LibreELEC/LibreELEC.tv
    Major Bump of nvidia Update from Latest Legacy GPU version (470.xx series): 470.199.02 to Latest Production Branch Version: 535.104.05…
    github.com

    You could try using an older LE release (older Xorg codebase with older drivers) or to use a more general purpose distro where things are less bleeding edge and you can still load and use older nVidia drivers.

  • Do script commands exists for LibreELEC to change power states, and can they be sent via USB?

    RPi4 can power off via scripted keyboard commands, but you cannot power on via the flirc USB receiver as the RPi4 board (when off) does not power the USB ports to receive the IR wake signal. The normal way around this with Pi 0/1/2/3/4 hardware is to have a power-board with IR sensor connected to the GPIO pins. The IR sensor is powered independently so can receive a wake command and then power-on the board via the +5v/GND GPIO pins not the normal USB-C connector. In that setup the Flirc USB receiver is redundant since you now have a permant IR sensor on the board.

    RPi5 should in-theory be able to do the USB-wake scenario as the RP1 and BCM2712 chips have the combined capability to support low-power states like 'suspend' where selected subsystems remain powered-enough to receive input and wake up again (as with some x86_64 hardware or Android boxes). The caveat is that this support requires firmware which is both complex and still actively being written (work in progress) so if you pre-ordered an RPi5 board today there's no guarantee that will work OOTB when boards ship or for some time after. It's definitely something that Pi devs are exploring and working on though.