Le Potato Segmentation Fault on Large File Transfer

@JohnBoyz: Thanks for the idea! I just removed the antenna completely - SNR goes from 33 dB down to 18 dB, and effects are the same (but /me receiving a good picture even without antenna shows how close I am to the transmitter :slight_smile:). I’m rather confident that it’s nothing about signal quality. And i did not want to move the topic to DVB-T2… So my question remains: Where would I configure timings? Is it possible at all? I remember some post quite a while ago that mentioned something about RAM timings and a config file for that, but for all I search, I can’t find it…

[EDIT]Did find it: RAM timing post - however: This seems to be more complicated than I thought…

Ive been doing more digging on my issue. I am not confident but we may be looking at bit rate issue for me. I took the same file 4K H265 Main 10 90mbps I believe and am running it through default setting on handbrake for 4K H265 MKV and it played considerably longer then the non converted file. The conversion will be another hours or so. In the mean time I am going to try some stupid high bitrate H265 clips and see what happens.

I have been testing LePotato+mainline+Kodi and the issues we have with the 3.14 kernel are definitely non existent, unfortunately the mainline work is very much in it’s infancy though.

Only the following works, MPEG 1/2/4, H.264, MJPEG, (partial) HEVC 8-bit.

There is no HDMI 2.0 driver or any of the other good stuff yet.

Good news. I have resolved my issue it deffinately has to do with a patch as last night I pulled the latest development branch and made the following changes

Changed the following files
-# CONFIG_FSTRIM is not set

CONFIG_FSTRIM is not set

                            --enable-libsmartcols \
                            --enable-losetup \
                            --enable-fsck \
-                           --enable-fstrim \
-setenv libretech "no_console_suspend logo=osd1,loaded,0x3f800000,${hdmimode} vout=${hdmimode},enable hdmimode=${hdmimode} cvbsmode=nocvbs consoleblank=0"
+setenv libretech "no_console_suspend logo=${logoopt} vout=${outputmode},enable hdmimode=${hdmimode} cvbsmode=nocvbs consoleblank=0"
+#setenv libretech "no_console_suspend logo=osd1,loaded,0x3f800000,${hdmimode} vout=${hdmimode},enable hdmimode=${hdmimode} cvbsmode=nocvbs consoleblank=0"
 if test "${hdmi_cec}" = "1"; then setenv cec "hdmitx=cec17"; fi
 setenv bootargs "console=${condev} ${bootrootfs} ${libretech} ${cec} ${libreelec}"
-ExecStart=-/usr/sbin/fstrim -a -v
+#ExecStart=-/usr/sbin/fstrim -a -v
+ExecStart=-/usr/sbin/fstrim /storage
Remove this patch

i could make my build available if someone is having similar issues to me.

I’ll certainly assist with testing your build if you’d like to upload it somewhere

Ill put it up on my google drive or somewhere tonight when I get home from work.

I want to try reverting a few of the changes I made to identify a specific cause to my issue. Ill share what I have so far.

C00l! Would love to test it and see if it fixes my file write problem also!

Here you guys go. I doubt it will fix the file copy issues but it is worth a shot.

Image removed as instructions are below and how to fix current release.

1 Like

My test is not scientific, it’s more “chaos monkey” based on actions known to cause problems, but it has been consistently repeatable within a short period of time on all previous builds. Using your dev build I have not yet gotten my box to lockup. Will keep monkeying around.

That’s good news. I had a video file I could consistently crash my lepotato 40 seconds in. My build is playing it perfectly fine. I’m in the process of building a new version with a few of my changes rolled back in hopes of fixing the video overlay issue I noticed and speeding up the boot process.

1 Like

I tried copying a 1.6GB file over NFS tonight and it worked just fine. I didn’t want to deal with getting rsync installed so I just used cp. Hopefully @oz-ra will be able to try his test as well. So far so good for me.

I am able to confirm that @ih8lag has found the root cause of the long standing segfault bug on LePotato.

It was related to a patch in u-boot added by kszaq designed to speed up the boot process, I would never have thought to look in u-boot myself.

bootloader.img (656.5 KB)

Download the above file to /storage and execute the following commands to replace your bootloader.

dd if=/storage/bootloader.img of=/dev/mmcblk0 conv=fsync bs=1 count=112
dd if=/storage/bootloader.img of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1

There is no need to download and reflash the whole OS if you don’t want to.


Hi adamg,
thanks for providing this! But no luck with me: First tried to patch my existing CoreElec 8.95.0, device failed to boot after the two commands and reboot. Did a clean install from the downloaded image, same result. Tried twice, just to be sure, second time with poweroff, disconnect from power, start cold. No success. Followed the instructions to the letter, cut’n’paste-ing the commands in the end.
Anyone with more success?
Cheers, Hauke


I have not tried @anon88919003 commands. After your report I tried the following:

Checked that I had a /dev/mmcblk0


dd if=/storage/bootloader.img of=/dev/mmcblk0 conv=fsync bs=1 count=112
dd if=/storage/bootloader.img of=/dev/mmcblk0 conv=fsync bs=512 skip=1 seek=1

that I found at: https://github.com/CoreELEC/CoreELEC/blob/master/projects/Amlogic/bootloader/update.sh

it Showed:

dd if=$SYSTEM_ROOT/usr/share/bootloader/u-boot of=$BOOT_DISK conv=fsync bs=1 count=112 status=none
dd if=$SYSTEM_ROOT/usr/share/bootloader/u-boot of=$BOOT_DISK conv=fsync bs=512 skip=1 seek=1 status=none

My System rebooted fine and I am now testing Network Transfers but it already looks fantastic, doing a 2.7GB restore successfully that would have failed in the past about 600MB in.

TL;DR I have not tried @anon88919003’s commands. The above worked for me. I will try his next.


@Hauke make sure you download the file to the location I specified, if you reinstall or update then you will have to do the commands again until we make a new release.

Ok I have retested.

Using Etcher and a fresh image every-time:

This hangs after I apply patch when I reboot:

Re-writing SD card with Etcher:

This reboots successfully after I apply @anon88919003 file

Thanks for everybody’s help. It is looking very good so far but will stress-test network transfers.

Hi oz-ra,
thanks for sharing this - indeed, adding “seek=1” to admag’s second command did the trick.
And I can also confirm that my large file copy problem is gone! Really happy! Thanks to ih8alg for finding this out!!!
My DVB-T2 problem is still there, so I was wrong that these problems were connected - however, this is a different topic, and I am still on rather old crazycat-drivers - will update next days, perhaps that’s it already.
Thanks again to everyone, will now reenable the recordings and see if the Potato survives!

Apologies for forgetting the seek=1 at the end, updated the post.

Thanks to anon88919003 and oz-ra i finaly could go from libeelec to the new coreelec.
:grinning: :grinning: :grinning:
I own an X96 (s905x) tv box with 2gb ram - wich worked rocksteady with the old libreelec and Kodi Krypton.
After switching to coreelec (for Emulation) the file transfer error occured.
Tested all available bootloaders with no luck - so i did go back to the old libreelec.
Now that rc3 was released - i tried again and failed. Same old transfer error.
But then i found your posts for the le potato (Wich has the same Chip)
and gave it a try. (gxl_p212_2g bootlader)
IT WORKS - no file transfer error until now.
thank you very much

CE NG builds require an android 7+ bootloader to function properly. I had the same issues with the same box.

Just on my way to work so I can’t give the long-winded, thorough explanation.

Search these forums for: TX7 - HQYG-TX7-nikodi-20180104 I’ve posted a link to the Android firmware Ive used on my x96 2/16 in other threads.

If you need more clarification, I can help when I get home later today.