Posts by RomMon

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    I had the same issue of the keyboard not working in Retroarch until I switched off the DS3 controllers.

    Every time I connected the DS3 controllers again I got a Retroarch message (in yellow) of the controller getting connected.

    After following @dtw_2000 steps here I got both controllers working again, and that also solved the keyboard issue getting non-responsive if the controller is connected.

    One question. What is the back button (back in the menu) on the keyboard in the Retroarch menu?

    Edit: strange I didn't find this before, it is: Backspace

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    Edit (2017-11-19):

    Restored to LibreELEC-Generic.x86_64-8.0-devel-20170621.img.gz for the moment, and with this image I don't have an issue stopping Spotify using [ALT]+[ESC].

    Edit (2017-11-12):

    Found a bit of a workaround.

    copied the Estuary skin to storage, and added a menu item to kill spotify, and start pulseaudio again.

    I haven't played much with it yet, but found just killing spotify + starting pulseaudio wasn't enough.

    See note below.

    Code
    cp -r /usr/share/kodi/addons/skin.estuary/ /storage/.kodi/addons/
vi /storage/.kodi/addons/skin.estuary/xml/Home.xml
:901
<add below additional menu item>
systemctl stop kodi
systemctl start kodi

    Item menu added:

    Code
    <item>
        <label>Stop Spotify</label>
        <onclick>XBMC.System.Exec(/storage/.config/stopspotify.sh)</onclick>
        <thumb>DefaultAddonMusic.png</thumb>
        <property name="id">Stop Spotify</property>
</item>

    NOTE: Below script isn't optimal, and I observe that I need to execute it twice to 'hear the click sound' while navigating the menu in Kodi. Killing spotify, and starting something with audio does work already with the first try. Executing the scrip form cli always gives the 'click sound' the first time, but not from within Kodi? (You can test with: sh -x /storage/.config/stopspotify.sh )

    Script:

    # cat /storage/.config/stopspotify.sh

    Bash
    #!/bin/sh
pkill spotify
sleep 3
#systemctl stop pulseaudio
#kodifreeze.sh freeze muteonly
systemctl start pulseaudio
#kodifreeze.sh unfreeze muteonly

    chmod +x /storage/.config/stopspotify.sh

    [/Edit]

    Edit 2 (2017-11-12):

    Just to give a better problem description including the use of above script:

    - Staring Spotify normally always works (99%)

    - Closing the Spotify window with [ALT]+[ESC] always works (100%), but nearly always (95%) of the time sound keeps going.

    - Using above script from CLI always works (100%) to kill Spotify and get sound back to Kodi.

    - Using above script from the added Kodi menu always kills Spotify (100%), and always works (100%) to have sound for started items (e.g. LiveTV, video, music), but menu-sound (moving through the menu with a remote gives a click sound) only get restored after a second time (100%).

    [/Edit 2]

    ==================================================================================================================

    Now playing with Spotify I do noticed sound keeps running after quitting (ALT+ESC).

    Had the same yesterday also.

    (LibreELEC-Generic.x86_64-8.2-devel-20171016.tar, cherry trail)

    ps shows spotify is still running.

    Code
    # ps -ef | grep -i spot | grep -v grep
 1904 root       0:00 {spotify} /bin/sh /usr/bin/spotify
 1916 root       3:58 /storage/.cache/app.spotify/spotify
 1918 root       0:00 /storage/.cache/app.spotify/spotify --type=zygote --no-sandbox --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474
 1939 root       2:34 /storage/.cache/app.spotify/spotify --type=gpu-process --no-sandbox --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,61,74 --disable-gl-extensions=GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent --gpu-vendor-id=0x8086 --gpu-device-id=0x22b0 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --service-request-channel-token=8C4AB353FFED75EF748DFAC7321F77CD --v8-natives-passed-by-fd --v8-snapshot-passed-by-fd
 1952 root       5:24 /storage/.cache/app.spotify/spotify --type=renderer --disable-pinch --no-sandbox --primordial-pipe-token=282CFD01371A42FB4697754B4D891313 --lang=en-US --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --disable-spell-checking --num-raster-threads=2 --enable-main-frame-before-activation --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553 --disable-accelerated-video-decode --service-request-channel-token=282CFD01371A42FB4697754B4D891313 --renderer-client-id=3 --v8-natives-passed-by-fd --v8-snapshot-passed-by-fd

    Edit (2017-11-06):

    The created spotify log is filling with '(spotify:1916): GLib-GIO-CRITICAL **: g_dbus_connection_send_message: assertion 'G_IS_DBUS_CONNECTION (connection)' failed'

    Edit2 (2017-11-06):

    Tried again, and this time ALT+ESC correctly terminated Spotify.

    Spotify log:


    Ps is still showing the old process running (1916):

    Code
    # ps -ef | grep -i spot | grep -v grep 1904 root       
 0:00 {spotify} /bin/sh /usr/bin/spotify
 1916 root       6:48 /storage/.cache/app.spotify/spotify
 1918 root       0:00 /storage/.cache/app.spotify/spotify --type=zygote --no-sandbox --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474
 1939 root       2:34 /storage/.cache/app.spotify/spotify --type=gpu-process --no-sandbox --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,61,74 --disable-gl-extensions=GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent --gpu-vendor-id=0x8086 --gpu-device-id=0x22b0 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --service-request-channel-token=8C4AB353FFED75EF748DFAC7321F77CD --v8-natives-passed-by-fd --v8-snapshot-passed-by-fd 1952 root       5:47 /storage/.cache/app.spotify/spotify --type=renderer --disable-pinch --no-sandbox --primordial-pipe-token=282CFD01371A42FB4697754B4D891313 --lang=en-US --lang=en-US --log-file=/storage/.cache/app.spotify/debug.log --log-severity=disable --product-version=Spotify/1.0.57.474 --disable-spell-checking --num-raster-threads=2 --enable-main-frame-before-activation --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553 --disable-accelerated-video-decode --service-request-channel-token=282CFD01371A42FB4697754B4D891313 --renderer-client-id=3 --v8-natives-passed-by-fd --v8-snapshot-passed-by-fd

    .

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    Edit3 (2017-11-04):

    Found a working microSD card (an older 16GB one).

    Code
    #dmesg
<snip>
[44958.212991] mmc2: new high speed SDHC card at address 1234
[44958.213697] mmcblk2: mmc2:1234 SA16G 14.6 GiB 
[44958.215760]  mmcblk2: p1
[44958.612711] EXT4-fs (mmcblk2p1): mounted filesystem with ordered data mode. Opts: (null)

#df -hT
<snip>
/dev/mmcblk2p1       ext4           14.3G     36.6M     13.5G   0% /var/media/mmcblk2p1-mmc-SA16G_0x2d4b0aeb

    Googling further found a reference to an Tronsmart forum thread (currently under maintenance):

    1397-micro-sd-card-compatibility-thread

    But already indicating the Tronsmart Ara X5 Plus is picky regarding microSD cards.

    [/Edit3]

    A microSD On the Tronsmart Ara X5 Plus is not working.

    I'm trying to use a FAT32 formated microSD card in the external microSD slot, but get the following error:

    Code
    # dmesg | grep -i mmc2
[    2.306880] mmc2: SDHCI controller on ACPI [80860F14:03] using ADMA
[    2.554270] mmc2: error -110 whilst initialising SD card
[  910.604454] mmc2: error -110 whilst initialising SD card
[  932.276147] mmc2: error -110 whilst initialising SD card
[ 1555.050434] mmc2: error -110 whilst initialising SD card

    (a timeout error according: Error -110 whilst initializing SD card - Raspberry Pi Forums)

    I tried a full format to FAT32 (on a windows machine), but no change.

    Edit (2017-11-03): tried a few other cards with same or similar results:

    Code
    Using a 64GB microSD card gives (from a RPi3 without reformatting):
[88714.382270] mmc2: error -84 whilst initialising SD card
Using a 8GB microSD card gives (from a RPi3 without reformatting):
[89282.452225] mmc2: error -110 whilst initialising SD card
Using a 128GB microSD card gives (from a RPi3 without reformatting):
[89418.383785] mmc2: error -110 whilst initialising SD card

    (error -84 is a 'illegal command sequence' according: error -84 (when hot?) - Raspberry Pi Forums)

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    escalade

    Didn't I pick the LTS version...?

    Thanks, yes was already preparing for that.

    (Only hope it doesn't become worse)

    Beside the normal LibreELEC backup are there other locations to backup.? E.g. I'm looking at /storage/.local/.

    Edit, from #1970 I knew I need to change /storage/.config/asound.conf to hdmi:CARD=Audio,DEV=2

    But is it expected that the output of aplay -L gives 3 possibilities?

    Edit2, Forgot to mention upgrade was successful. Only the CEC adapter didn't work immediately after the first boot, but did after some minutes without a reboot.

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    Edit (2017-11-05): I have not observed these 'continuous' crashes after:

    1) upgraded to LibreELEC-Generic.x86_64-8.2-devel-20171016.tar (cherry trail specific image).

    2) replaced my USB3-HUB (including its power supply).

    I suspect the upgrade solved the 'continuous' crashes. The replacement of the USB3-HUB looks to have solved the difficulty to power-up the system with all devices connected. (I think my old hub had a power related issue).

    I'm still monitoring my system, and still see a Kodi crash once in a few days, but that looks different from this issue.

    [/edit]

    For some time (few weeks I suspect) Kodi is crashing often.

    I thought it was a USB 3.0 Hub, but today without this hub connected I observed the same issue.


    I cannot reproduce it easily, but if it is present it is sometimes difficult to get the HTPC working normally again.

    E.g. multiple reboots or even multiple power-cycles (but without the USB-hub, this looks less of an issue)

    I'm a bit afread it is hardware related.


    Hardware details:

    - Tronsmart Ara X5 plus (Intel Atom x5 Z8300 cherry trail),

    - Pulse-eight CEC USB Adapter (in use from 15-July-2017)

    - Anysee E30 ComboPlus TV tuners

    - IMON LCD display

    Firmware version:

    LibreELEC, Install Extended Community Build, LibreELEC-Generic.x86_64-8.0-devel-20170621.img.gz

    dmesg shows a lot of segfault e.g.:

    Code
    [154419.211720] kodi.bin[30859]: segfault at fffffffffffffff8 ip 00007fbc953d315b sp 00007fbc13ffeb20 error 5 in libstdc++.so.6.0.23[7fbc95302000+172000]

[154432.493005] traps: kodi.bin[31062] general protection ip:7fe94a2bf08b sp:7fe8a3ffe890 error:0 in libc-2.25.so[7fe94a248000+190000]
[154444.005243] traps: kodi.bin[31174] general protection ip:7f323563108b sp:7f31de7fb700 error:0 in libc-2.25.so[7f32355ba000+190000]
[154454.266729] kodi.bin[31327]: segfault at 8038440 ip 00007ff108026490 sp 00007ff123013d08 error 6

    And also '09_Journal-cur.log' shows the crashes.


    The TVHeadend log '11_Addons.log' gives some hints when this might have started. Searching for 'Disconnected' gives the timestamps.

    (continuously from 2017-10-31 00:23:10.035 till 2017-10-31 10:44:17.913 when the logs where taken.)

    I hope it is possible to identify a cause from the logs.

    (I removed '05_Network.log' from the archive, found it revealing quite a bit if details. Ssh is working during the crahses, so don't expect the issue to be network related.)

  • RetroELEC Kodi+Wayland+Emulationstation+RetroArch (x86/XU4/RPi)

    Does the Tronsmart Ara X5 Plus support 3D playback? (yes, see edit below)

    I have a Tronsmart Ara X5 Plus with 'LibreELEC-Generic.x86_64-8.0-devel-20170621' installed.


    My TV is a Samsung UE40D6530, which does support 3D (using active glasses (SSG-3050GB)).

    With the RPi3 I can watch a movie in 3D (for a minute, until the cpu gets too hot, and starts to throttle).

    But with the same settings, 3D playback in not working on the Tronsmart.

    3D settings (default):

    - Settings > System settings > Display > Stereoscopic 3D mode / Current > Disabled

    - Settings > System settings > Display > Prefered mode > Same as movie

    - Settings > Player settings > Video > Playback mode of stereoscopic 3D videos > Ask me

    - Settings > Player settings > Video > Disable stereoscopic 3D mode when playback ended > selected

    I'm happy with the Tronsmart, I do miss CEC support enormously (found that Pulse Eight has a solution for that).

    3D would be nice, but can easily live without.

    All other (Live-TV, iMon display, external HDD, ...) is working better than with the RPi3.

    Escalade, thank you for this build.

    Edit (2017-07-21):

    • 3D:

    Got 3D playback working. On Kodi I keep the default selection, and it will output 'side by side' Stereoscopic 3D mode. On the TV (e.g. using '3D' button on the remote, or via menu) also select the 3D side by side option. And it should work.

    • CEC:

    Received the 'Pulse eight CEC usb adapter', and it works great.

  • Scripts clean used for busybox casuses rebuilt toolchain

    I'm building in a vm with Ubuntu 16.04.

    Ok, so the e2fsprogs re-build issues is a known/resolved issue for a future release.

    (I'm not familiar with github enough to find more details about commit 14f5fef e.g. why didn't it make it in 8.0.x.)

  • Scripts clean used for busybox casuses rebuilt toolchain

    Second part

    After building a lot of packages make fails while building kodi

    PROJECT=RPi2 ARCH=arm make image

    Failure messages

  • Scripts clean used for busybox casuses rebuilt toolchain

    Using the clean script for busybox seem to cause a rebuild of the build environment(, and fails with compilation of e2fsprogs).

    (same for using the clean script for e2fsprogs)

    Initial state:

    Initially I successfully compiled an 'stock' 8.0.2 image (see [Fixed] Compile error LE 8.0.1, xz: (stdin): File format not recognized), following the wiki page: index.php?title=Compile

    Re-compile busybox

    To re-compile busybox (e.g. without any config changes made yet) I expected the following would be the required steps:

     PROJECT=RPi2 ARCH=arm scripts/clean busybox

     PROJECT=RPi2 ARCH=arm make image


    I hoped the script more to behave like:

    cd ~/LibreELEC.tv/build.LibreELEC-RPi2.arm-8.0.1/busybox-1.25.1/

     make clean

     cd ~/LibreELEC.tv/build.LibreELEC-RPi2.arm-8.0.1/.stamps

     rm -r busybox


     
    Questions

    1) Is it expected behaviour that 'scripts/clean busybox' cause so many packages to be rebuild?

    2) What are the advised steps to re-compile busybox for the target (PRi2)?

    3) Is it possible/needed to properly fix the 'Permission denied' failures for re-compiling e2fsprogs?

    4) Is there a fix for the second make error "Could NOT find FreeType (missing: FREETYPE_INCLUDE_DIR) (found version "18.5.12")"?


    Resulting steps

    (long list just to give in idea how many packages are rebuild)

    Error e2fsprogs:

    Code
    make[1]: Leaving directory '~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/e2fsprogs-1.43.3/.x86_64-linux-gnu/lib/ext2fs'
cp: cannot create regular file '~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libcom_err.a': Permission denied
cp: cannot create regular file '~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libext2fs.a': Permission denied
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 1

    Workaround for 'Permission denied' failure

    Code
    ls -la ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libcom_err.a
ls -la ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libext2fs.a
mv ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libcom_err.a ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libcom_err.a.orig
mv ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libext2fs.a ~/LibreELEC.tv.test/build.LibreELEC-RPi2.arm-8.0.2/toolchain/lib/libext2fs.a.orig
PROJECT=RPi2 ARCH=arm scripts/clean e2fsprogs
PROJECT=RPi2 ARCH=arm make imag

  • shadow file permissions different from build directory

    vpeter

    Thanks for clearing that up.

    It does give me an error messages while re-squasing:

    Code
    Failed to read file ~/LibreELEC.tv/deleteme/squashfs-changed/etc/shadow, creating empty file

    I have not het tried to use a re-squashed image yet, but the file in a compiled image is not empty.

    Had also a bit similar questions regarding /usr/bin/busybox and /usr/lib/dbus/dbus-daemon-launch-helper, but you clear those also.

    (e.g. LibreELEC.tv/package.mk at master · LibreELEC/LibreELEC.tv · GitHub

    LibreELEC.tv/package.mk at master · LibreELEC/LibreELEC.tv · GitHub)

  • shadow file permissions different from build directory

    While looking into unsquash/re-squash an image I see that the file permissions of an image are different from the build directory for /etc/shadow.

    Build directory:

    Code
    ls -l ~/LibreELEC.tv/build.LibreELEC-RPi2.arm-8.0.2/image/system/etc/shadow

-rw------- 1 <user> <group> 205 Jun  5 15:04 ~/LibreELEC.tv/build.LibreELEC-RPi2.arm-8.0.2/image/system/etc/shadow

    On RPi3 (self compiled 8.0.2 image):

    Code
    ls -l /etc/shadow

----------    1 root     root           205 Jun  5 09:04 /etc/shadow

    Is it expected that there is a difference?


    (unsquashed:

    Code
    ls -l ~/LibreELEC.tv/deleteme/squashfs-root/etc/shadow 

---------- 1 <user> <group> 205 Jun  5 15:04 ~/LibreELEC.tv/deleteme/squashfs-root/etc/shadow

    )

  • [LibreElec 8.0.2] Media transfer stops halfway: "read-only file system"

    I have similar issues with LE 8.0.1, and suspected my hardware (dual hdd enclosure).

    Can you verify directly after an event with:

    Code
    mount

    and verify if the USB drive got a new 'device node' assigned (e.g. /dev/sdb1)?

    Also check the last lines in the output of:

    Code
    dmesg

    and look for hdd related messages.

    The drive that showed this behavior in my setup is an ext4 partitioned drive.

    (I'm not near my RPi, so cannot verify the messages I have seen.)

    Edit (2017-05-28): I only started to use this (dual) USB HDD after having 8.0.1.

  • [Fixed] Compile error LE 8.0.1, xz: (stdin): File format not recognized

    Buzzthebuzzsaw, vpeter,

    With your combined advice I finished my first image.

    Code
    $ ls -la ~/LibreELEC.tv/target/
<snip>
-rw-rw-r--  1 <user> <group> 131687220 Apr 30 04:34 LibreELEC-RPi2.arm-8.0.1.img.gz
-rw-r--r--  1 <user> <group>   5932496 Apr 30 04:31 LibreELEC-RPi2.arm-8.0.1.kernel
-rw-r--r--  1 <user> <group> 134369280 Apr 30 04:32 LibreELEC-RPi2.arm-8.0.1.system
-rw-rw-r--  1 <user> <group> 145111040 Apr 30 04:33 LibreELEC-RPi2.arm-8.0.1.tar
$

    The only change I made was with ~/http://LibreELEC.tv/packages/tools/dtc/package.mk changing the download from a xz compressed file to a gzip compressed file.

  • [Fixed] Compile error LE 8.0.1, xz: (stdin): File format not recognized

    Buzzthebuzzsaw,

    You are right it is not a tar.xz compressed file but tar.gz.

    Code
    $ file dtc-1.4.2.tar.xz  
dtc-1.4.2.tar.xz: gzip compressed data, from Unix  
  
$ file bcm2835-driver-2ef9cb6.tar.xz  
bcm2835-driver-2ef9cb6.tar.xz: XZ compressed data

    On the site I also only see tar.gz sources available: dtc/dtc.git - The Device Tree Compiler

    Changing it to a tar.gz makes it continue:

    Code
    vi ~/LibreELEC.tv/packages/tools/dtc/package.mk  
 change PKG_URL="[url]https://git.kernel.org/cgit/utils/dtc/dtc.git/snapshot/$PKG_VERSION.tar.xz[/url]"
 to PKG_URL="[url]https://git.kernel.org/cgit/utils/dtc/dtc.git/snapshot/$PKG_VERSION.tar.gz[/url]"
rm ~/LibreELEC.tv/sources/dtc/dtc-1.4.2.tar.xz*
cd ~/LibreELEC.tv
PROJECT=RPi2 ARCH=arm make image

    The md5sum is still the same, but now for the correct filetype:

    Code
    $ cat ~/LibreELEC.tv/sources/dtc/dtc-1.4.2.tar.gz.md5
04891daf4544da49958b60109ed4beb1  sources/dtc/dtc-1.4.2.tar.gz


    make output:

  • [Fixed] Compile error LE 8.0.1, xz: (stdin): File format not recognized

    Get the following error while compiling a LE 8.0.1 image.

    Last lines of the output:

    Code
    UNPACK   bcm2835-driver
  UNPACK   dtc
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 2
@libreelec:~/LibreELEC.tv$

    Based on the output I get that the unpack of dtc fails.
    But don't see an issue with the file.


    Compiled on a newly created VM with Ubuntu 16.04
    Commands used.

    Code
    sudo apt-get update
sudo apt-get upgrade
sudo apt-get install gcc make git
sudo dpkg-reconfigure dash
cd ~
git clone [url]https://github.com/LibreELEC/LibreELEC.tv.git[/url]
cd ~/LibreELEC.tv
git checkout 8.0.1
PREFER_PACKAGE_MIRROR=yes PROJECT=RPi2 ARCH=arm tools/download-tool
PROJECT=RPi2 ARCH=arm make image


    Link to last ~2000 lines output.
    https://forum.libreelec.tv/thread-7906.html - Pastebin.com