Posts by chewitt

  • Libreelec on old hardware

    The issue is not whether you can install LE on it (maybe) but whether it runs any good once it's installed. Old laptops are generally slower, noisier, with worse media support, and use more power than an older Raspberry Pi2/3 board. Experimenting is $free though :)

  • RPi controlled by IR remote: is it possible to turn it on by it?

    RPi has no native IR capability so needs an additional device with independent power and IR receiver that can control the main power to the board, either by being inline to the normal power connector or through driving power input pins on the 40-pin connector. It is not possible to use a GPIO receiver because the GPIO pins on the 40-pin connector need power before they can receive anything.

  • RPi4 1GB sufficent replacement for RPi0W?

    Our normal response would be that the 2GB RPi4 is the minimum RPi4, but that's considering 4K support which you probably don't/won't need in a space constrained RV installation. It has newer/better/more-efficient design and considerably more CPU grunt which is always a good thing. It also allows you to run LE10/LE11 so is more future proof (we already dropped support for Pi0W) and you'll have native HEVC hardware decoding. As long as it's not a crazy price it would definitely be an improvement. Then again, so would an RPi3B+ which you might be able to pick up cheaper/easier somewhere. Not as future proof, slower, and similarly 1GB RAM constrained but still a worthy bump.

  • Where to patch dvb driver in LibreELEC 9? Overlay confuses me...

    LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.

    If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).

  • About new board based on RK3399

    a) Patch upstream kernel sources to include the dts and build the dtb

    b) Patch upstream u-boot sources in include the dts with a u-boot config file

    c) Generate patches for the kernel and u-boot changes; ensure those patches apply on-top of existing LE package patches

    d) Add patches to the 'patches' folders of either the packages or under projects/Rockchip/devices/RK3399/patches/(linux|u-boot)

    e) Modify scripts/uboot_helper to add a device using the kernel dtb and u-boot config file

    f) Build the image

    There aren't really instructions for this anywhere; GitHub commits serve as 'prior art' and there's a deliberate low-bar requirement for some initiative and general understanding of how distro image building and build-systems work.

  • Wetek play 2 build

    There is no recovery script; it should prompt the box to re-read the u-boot scripts (s905_autoscript etc.) which will load the LE kernel file and dtb into memory and boot them. I'd need to see UART (serial console) output to understand where it goes wrong - it's always worked for me and others in the past. WeTek did ship UART cables with the box but I'd expect most folks to have chucked it out by now? - The wetek-play2 image boots the device from SD card using upstream u-boot; but only if the eMMC has been erased (removing vendor u-boot) first, and the best way to do that is booting the device from the box image (catch 22).

  • Upgrading from LE 9 to LE 10, no addon support?

    Hard to say without seeing a proper debug log file, but the reason why we have written "DO NOT UPDATE, CLEAN INSTALL" all over the LE10 release notes is that add-ons cause issues due to the Python 2 to 3 changes. If you're comfortable at the command-line I'd stop Kodi and rename /storage/.kodi to /storage/.kodi-old and then restart Kodi. You now have clean instance and can clean install add-ons so they work and stop/move-stuff/restart bits of Kodi content to manually restore the essentials like thumbs, sources, databases, add-on settings, etc.

  • How do we know when a new version will make DB changes?

    You'd have to track Kodi development to spot the schema changes that result in DB 'version' bumps. If you're using MariaDB the DB versions are now different for K19 and K20 but that only results in you having two active DB versions. You will have to scrap content twice (once for each version) and might end up with occasional differences in content due to changes in scrapers outputting different results, but overall things coexist (in ignorance of each other) and the only thing that doesn't work is tracking of watched/play status. I run in the same way due to ongoing testing and do an occasional "marking things watched" run on the K20 database (as K19 is still the family daily-driver where the changes accumulate). However my kids mostly watch the same stuff over and over so I don't make too much effort to keep things in sync as they'll quickly catch up once K20 becomes the main DB.

  • LibreELEC-RPi4.arm-9.2.8.img

    The latest iterations of RPi4 board need newer firmware than we ship(ped) some time ago in the LE 9.2.8 image. You either need to run LE10 or venture into experiments with the newer boot files copied to the LE 9.2 image (Start.elf and one other, I forget the name).

    Unless you have a really good reason to need LE 9.2, the LE10 codebase is some way ahead and should be used.