Posts by Iridium

    @vpeter.Thanks, that all worked as hoped.

    For others: What I did was.
    1) Installed LE normally onto the SD card, boot it and let it resize, reboot and initialize (Allow any addon updates to finish). Shutdown.
    2) Format your new eSata drive as ext4 (Give it an unique LABEL or new UUID)
    2) Copy everything as root (Includes .<files>) from /dev/mmcblk0p2 to /dev/sda1/storage (eSata drive).
    3) Remove /dev/mmcblk0p2 from the SD card) Not needed any more.
    4) Edit uEnv.txt and change disk=/dev/mmcblkp02 to either:
    disk=/dev/sda1 (If only one disk will ever be attached) - best not to use.
    disk=LABEL=<eSata disk label> as set in (2)>
    disk=UUID=<UUID> as set in (2).

    Connect the eSata cable to the eSata port, and the power to a USB port.

    Power up the Cubox and if all has gone well, the disk I/O should be significantly improved.

    Go back to basics. The RPi1 doesn't really have the horsepower to show 1080p movies reliably especially over the network..
    You need to find where the bottleneck is.
    Use a fresh install of LE with no other addons or other detritus.
    Use the same movie on NAS/USB/SD and see if there is any difference.
    Use LE addons System-tools and NMON to monitor where the issue is, CPU, I/O, N/W.

    You can't say (as much as i hate to say this, this didnt happen on openelec) as you probably aren't using the same parameters i.e same setup, nor same movie.

    LE is a readonly file system however instead of /usr/bin you could create /storage/bin folder and add PATH=$HOME/bin:$PATH to .profile. It

    To run it at startup add the program to /storage/.config/autostart.sh

    You may also need to add the LE addon RPI-tools which contains most modules for GPIO usage.

    If I understand correctly, during boot the KERNEL, SYSTEM and mx6q-cubox-i.dtb ( I assume some load points) are loaded into memory from the SD card and /storage is defined from uEnv.txt = in my current case /dev/sda2

    However, I don't need boot =/dev/sda1 as it is already loaded from the SD card, so I just need disk=/dev/sda1 in uEnv.txt (As I no longer need the boot partition) which is /storage - which is the whole eSata disk.

    So, I'm hoping in uEnv,txt, if I'm correct, that all I need is the boot=/dev/mmcblk0p1 on the SD card and disk=/dev/sda1. (UUID - whatver)

    So I don't need /dev/mmcblk0p2

    So: If I'm correct

    SD card: Only contains system files on /dev/mmcblk0p1
    eSata : Only contains /storage on /dev/sda1

    As all system I/O is done in memory there is not need to load LE onto eSata for any performance gain.

    Am I correct?


    I can ssh into the Pi and would like to overclock the 700 mhz to 1ghz cpu. But normally i see a ton of options in the config.txt but there isnt any option to remove the "#" line under the Overclock section.

    Looks normally something similar to this:
    arm_freq=1000
    sdram_freq=500
    core_freq=500
    over_voltage=2

    But in previous Openelec versions all the options were pre-typed into the config where i dont have to type anything just remove the comment on whatever line i wanted to use. I dont want to mess up anything by having to handtype anything. I also put the SD card into the computer and it was still missing. Any and All help is appreciated!

    See Config.txt - LibreELEC for how to.
    RPiconfig - eLinux.org

    I would seriously reconsider jumping to 1Ghz but work you way up and see how reliable it is over time.

    The correct values for 1Ghz are:
    arm_freq=1000
    sdram_freq=500
    core_freq=500
    over_voltage=6 <<<<<< Not 2 >>>>>>

    Just cut and paste the values into config.txt via ssh.

    However, I do agree it would be nice if the default config.txt had most of the usual parameters commented out as default.

    Firstly I would try using an ethernet cable and see if you get the same results.

    Also I would look at your "ping" especially as the delay is increasing over time. Try ping -c 20 <IP>and see if it times out.

    'Disconnected: No supported authentication methods available (server sent: publickey,keyboard-interactive)' is due to "Disable Root Password" being set.

    Double check your LE network settings - try manual instead of dhcp to see if that solves the issue.

    Also supply logs: dmesg and kodi.log

    Years ago, I played around with a kickstarter project called "HotPi" which did exactly what you are hoping to achieve (albeit on the RPi1). Some of the documentation may still be around which will give you a few clues. However, I think you may run into problems if some of the python modules are not available in LE.

    Also, I found that the noise of the fan was annoying whilst watching a movie.

    If you're overclocking the RPi3 (and possible other performance "tweaks") your going to have to expect temperature problems.

    Ways around it are to remove the lid of a case if any, install a heatsink (don't use a heatsink if enclosed in a case - counter productive without a fan).

    What I ended up doing, was just using a small 5V fan connected to 3.3V and Gnd. It's slow enough to be quiet but effective enough to keep the temperature around 40 degrees with normal usage.

    A red thermometer is the sign of overheating (Actually when the RPi3 throttles back) a yellow zigzag is a sign of voltage issues.

    You won't be able to see what processes are using the system as the system is still starting up - having transmission, couchpotato and sonarr are not going to help unless they are delayed on startup.

    "Successfully removed storage" = An attached device has been unmounted - do you have an HDD attached - and if so HOW - Powered USB hub or direct to the RPi? - My guess it's not a powered USB hub. The voltage is dropping and the HDD detects this and powers down. Probably also then tries to power up again as the voltage increases.

    The "overheating" should not be the issues as the RPi3 will just throttle down.

    Heatsinks in a case are not much use if the "HOT" air cannot get out. Remove the lid or think about getting a small fan and attached the leads to the GPIO pins (either Pin1 for a slower fan speed +3.3 or Pin2 for a faster speed +5 and ground to Pin6 - )

    If it's only occasionally (as when you are updating something) then I wouldn't worry too much.