Posts by chewitt

Quote from kmihmisc

I am running Raspbian Jessie LITE with KODI Jarvis V16 updated by doing a "apt-get" from pipplware.pplware.pt. I was under the impression that the people who wrote LibreElec were also involved in the KODI / Raspberry Jessie Lite project. Please correct me if I am wrong. Is this an issue that should be reviewed by the Raspberry Jessie LITE or KODI project developers?

There are a small number of people who are members of both project teams. However you are in the LibreELEC forum where we discuss and take interest in "Kodi on LibreELEC" issues. If you want support for "Kodi on something else" the questions belong in the Kodi or the other distros' support forum (Kodi's would be my recommendation). It's not that we're trying to be difficult .. I'm one of the 3-4 people who sits in both teams and I've never booted anything but LibreELEC on pi hardware or installed Debian on anything else, so I'd suck at guessing what your Jessie Light problem is.

I'm still building official things on 16.04 which works fine as I created a 7.0.2-ish image yesterday. We're not really interested in trying to solve custom build issues on the 7.0 branch as Jarvis is basically a closed book now, but if you create a Krypton build (master branch) it will use gcc 6.2 which might sidestep the version issue. Despite the 'Alpha' working label Raspberry Pi builds are extremely stable.

What distro are you compiling on? .. in theory it makes no difference, but in practice it can.

A note for anyone self-building things from my slice-8.0 branch on GitHub:

Gordon figured out how to make Kodi correctly detect an IEC958 device which allows the S/PDIF output to send lovely 5.1 output to an AVR *BUT* you must ensure the "Sync playback to display" option in System > Playback is disabled for multi-channel audio to work. If you have SP2D enabled *all* audio is resampled to 2.0 PCM. In older Isengaard/Jarvis Kodi builds it's possible to have SP2D enabled and still get multi-channel output (sort of a bug that's fixed in Krypton) so if you update to these builds this might catch you out.

NB: The snd_slice.conf to enable 5.1 output will be in v7.90.009 which is sort of ready but waiting for Kodi 17-beta 6 which is taking an age to be released due to some unresolved addon update/crash bugs affecting Windows Kodi builds.

Random thoughts following the investigation of some weekend investigation fo Raspberry Pi DAC cards:

a) Some devices need IEC958 to be declared properly .. see here:

snd_slice: add 16-bit support and initial IEC958 conf · chewitt/LibreELEC.tv@9d91337 · GitHub

b) If you have "Sync Playback to Display" enabled in Krypton builds everything will be resampled to 2.0 PCM

If you read the text on the download page, the bit where it says "For all other downloads (files to use with 3rd party SD creator tools, manual update files, NAND install files, noobs files, files to migrate you from OpenELEC, etc.) please select your hardware in the drop-list below:" .. and then click in the drop list you can navigate away from the Raspberry Pi downloads to the Generic AMD/Intel/nVidia image downloads.

To recover an existing installation either create a new LE USB and attach a keyboard, then boot from the USB and CTRL+ALT+F3 to access a local console where you can mount the internal drive and download/extract/replace the KERNEL/SYSTEM files in the boot partition. Or create an Ubuntu LiveUSB and use GUI tools there to do the same thing.

NB: LE has mechanisms to detect and abort updates when people load the wrong files, but when you first update from OE you're using OE's older update process and this has no protection.

Quote from apc

So how complete would a restore be after for example burning a new LE image as a completely new install.

As long as you don't store media on /storage it should have everything necessary.

Update to 7.90.008 and if no change connect the HTPC directly to the TV (no AVR) and test again.

No plans to enhance our one-time backup option because Add-on:Backup - Official Kodi Wiki already exists

If the USB drive is HFS+ formatted for macOS it will mount read-only under Linux. There are several ways to deal with this, but the least complicated option is to move all data off the drive, reformat it using exFAT instead of HFS+, then copy data back.

I think the best option is a simple finned heatsink that can be attached with a small dab of [heat] conductive paste and a small elastic band around the SO-DIMM board to hold it in place. This would be simple for users to apply and doesn't result in direct contact with the casing. Solutions that achieve case contact will be thermally more efficient but there's a higher risk of mechanical damage; not from thermal flexing, but when a fat-fingered user puts a huge gob of paste on the CPU which uses all the tollerance up and places stress on the SO-DIMM connector. The CM3/Slice has been designed to run quite happily at high temperatures so the goal of adding heatsink is not to achieve the best possible thermal transfer; only to reduce the temperatures enough to keep the thermometer off-screen. I'm only seeing it during large library scans or when trying to software decode HEVC content that it can't handle (with any level of overclock) so it's not really a big deal.

SD cards and USB sticks are equally crap and unreliable IMHO. I would keep things simple and run from SD card, but spend time organising a nightly (or weekly minimum) backup so that when (not if, when) things go wrong it's not a major inconvenience. If you want something faster to boot and scroll around in menu's with (and more reliable) spend $$ and get the eMMC card.

Appendix B. X Config Options lists all nvidia config options available for the current driver that we use. The only item I can see there that might be related is AddARGBGLXVisuals but nothing really stands out.

mkpkg_kodi only packages the Kodi source files; next you need to copy them to sources/kodi and fake the matching .url and .md5 files and then configure the kodi package.mk so that PKG_VERSION contains the correct githash, or you host them on a local server and change PKG_URL (and PKG_VERSION) in the kodi package.mk. The first option is probably easier.

pvr.zattoo is an addon so "PROJECT=RPi2 ARCH=arm scripts/create_addon pvr.zattoo" will build it, then you can install the zip via Kodi GUI. The add-ons we embed in the image are built as packages (similar but different package.mk) not add-ons.

setenv bootrootfs "boot=/dev/mmcblk0p1 disk=/dev/sda1"

Change the boot/disk configuration in boot.ini to look like and it should work? You must partition/format the USB to use EXT4 first.

Quote from darren3976

will this work on libreelec 64 bit

It will work on x86_64 (Generic). It will not work on aarch64 for the reasons already explained above.

Once you add a case, wireless, bluetooth, cables, PSU, and a decent USB tuner, etc. the price difference between C2 and WP2 won't be so large. If you like the DIY approach you'll favour the HK product. If you like everything shrinkwrapped the WeTek box will look good. They're different devices created to suit different consumer tastes.

No random PM please. I've nothing more to say in private than I'll post here.

Hub has the newer S905-H chipset which is considerably better than the older MX chip in the WeTek Play v1. WeTek Play v2 uses exactly the same S905-H chip as the Hub but has more RAM and a Tuner card.

If you want something rock solid with LE the Raspberry Pi v3 is probably the best supported and most stable device, but it sadly doesn't have 4k/HEVC capabilities.