That's not an error.
Did you actually copy your public key to your device before disabling password authentication?
I didn't copy any key or anything. I just followed your suggestion. Now that its set back to "normal" I'm not going to bother any more - maybe it's a IMX6 thing.
I'm surprised there are no answers yet.Is no one using Libreelec with NAS as all of them must be affected or waiting for stable release?
You posted the question:
Yesterday, 10:08 (This post was last modified: Yesterday, 10:44 by djfelixus.)
That was just ONE day ago!!
You didn't explain if you had upgraded or a fresh install?
I know there was an issue earlier with SMB, so either remove the source and add it again or use explicit paths like smb:/192.168.0.xx rather than smb://<server>
I'm not convinced it's a bug. The memory is being used, just not ALL at once. The amount of memory used, is going to be based on the size of data required for playback multiplied by the readfactor. (unsure where the 3 times memorysize comes into it).
I use a Cubox (orig) running Archlinux as a NFS server with a Gigabit network, going to wifi on a 300Mbit extender back to Gigabit into a Cubox-i4 running LE. I've never had any issues with buffering, even with very large files.
You need to check the usage on all sides. Remember a RPi only has a 10/100base ethernet and max speeds are only in the region of ~40Mbs.
Use the tools available in the LE Repository, Network and System Tools. Use something like nmon/iperf to monitor the amount of data coming in and determine the maximum size received.
The way I think of it, is as a water supply.
[R1] ---P1--- [R2] --> U1
R1 is a reservoir (your NAS/Internet streaming provider)
P1 is a pipe (The bigger the pipe the more water can be supplied per second) (Your network).
R2 is a reservoir (Kodi buffering) - The size of the "reservoir" is set by memorysize.
The amount of water fed into the reservoir is determined by the amount being used by U1 multiplied by the readfactor.
So as long as enough water is coming through P1 to satisfy U1 then you should have no problems. R2 will fill as quickly as possible but if P1 or R1 cannot supply enough, then lagging and buffering will occur.
I have a feeling that if P1 can supply more to U1 than R2 can accommodate, then problems will occur (Dam burst), which might explain my problems with readfactor of 60.
Kodi buffering will NOT help a bad network/server, nor will it help a slow processor (Wait times loading the data).
Personally, I think the default LE settings i,e NO advancedsettings.xml should work for most users. If you must use it, adjust it incrementally and check your data.
What error?
Permission denied (publickey,keyboard-interactive).
By default LE will only recognise an eSata drive if it is connected at boot. To allow hot plugging of eSata devices you only need to do a few things.
1) Make /flash rw
mount -o remount,rw /flash
2) Then make a backup of uEnv.txt
cp /flash/uEnv.txt /flash/uEnv.txt.orig
3) Edit /flash/uEnv.txt
nano /flash/uEnv.txt
and add ahci_imx.hotplug=1 to the end of the line. So it looks something like this
mmcargs=setenv bootargs "boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 ${ssh_arg} ${console_arg} ${debugging_arg} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 dmfc=3 consoleblank=0 ahci_imx.hotplug=1"
Save with <Cntl> O and Exit with <Cntl> X then reboot.
I deleted /storage/.cache/services/sshd.conf and re-enabled ssh in Kodi and all worked as expected.
However, setting "Disable SSH Password" caused the error to re-appear.
Interesting, I use this on IMX6 with 2G memory and didn't see any change in memory usage either.
<advancedsettings>
<cache>
<buffermode>1</buffermode>
<memorysize>209190912</memorysize>
<readfactor>20</readfactor>
</cache>
</advancedsettings>
The readfactor does work, as you can see a change in the amount of buffering in the video playback position. readfactor=60 did break it though!
Balcmeg - Yes I use a Cubox-i4 (Amongst others) although at the moment I am sticking to 7.90.010 because of sound issues - already posted.
I only tried a new boot, to see what the issue was, I didn't go much further than that.
Please remember that the IMX6 issue is a community build and will always be behind the "better" flavours.
Personally I wouldn't use <memorysize>0</memorysize> as all buffering is going to the SD card and not memory (This is slow compared to memory and increases the I/O on the card - which are not fast at the best of times.
Try <memorysize>139460608</memorysize>, <readfactor>10</readfactor> (Increasing to 20 if all works)
I tried echo 'SSHD_DISABLE_PW_AUTH="true"' > /storage/.cache/services/sshd.conf on IMX6 and it didn't seem to work - so I ignored it. Now after a reboot I cannot ssh into it any more.
on OSX (Darwin)
ssh [email protected]
Permission denied (publickey,keyboard-interactive).
on Android JuiceSSH
Just keeps asking for password which is still libreelec.
Not sure if it is related as I removed the line from sshd.conf and the problem still exists. I've tried setting no password in Kodi and turning ssh on and off again but with no success.
I've just done a clean install of 7.95.3 and it boots normally. (Has it been fixed already?)
Output from serial connection:
U-Boot SPL 2013.10-rc4 (Feb 09 2017 - 05:34:44)
Boot Device: SD1
U-Boot 2013.10-rc4 (Feb 09 2017 - 05:34:44)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: WDOG
Board: MX6-CuBox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC [PRIME]
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot: 0
mmc0 is current device
** Unable to read file /boot.scr **
532 bytes read in 14 ms (37.1 KiB/s)
Importing environment from mmc0 ...
9092976 bytes read in 417 ms (20.8 MiB/s)
Booting from mmc ...
34894 bytes read in 20 ms (1.7 MiB/s)
Loaded imx6q-cubox-i.dtb
Booting /KERNEL
Kernel image @ 0x10800000 [ 0x000000 - 0x8abf70 ]
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800b84d
Starting kernel ...
Balcmeg Can you change the title to Cubox-i to avoid confusion. Tnx
I hoping your are using a Cubox-i and not the original Cubox (Armarda/Marvell 510)
The Kodi mute function is usually keyboard F8 Sounds like some key on your remote has been set for this. I would check you keymaps Keymap - Official Kodi Wiki or use the Kodi addon Add-on:Keymap Editor - Official Kodi Wiki
What version of LE are you running and on what device?
Quote "I've added this code to my advancesettings.xml file:" Maybe it's just a typo but check the file is "advancedsettings.xml" (Note the "d")
Same issue with 7.95.2
I believe vpeter is looking at this.
I'll do a clean install of 7.95.2 and see if this eliminate the problem.
On boot, I see in dmesg
[ 2.315278] rtc-pcf8523 2-0068: setting system clock to 2017-02-11 17:26:36 UTC (1486833996)
So the HW clock is working fine, however about a minute later in journalctl
Feb 11 17:27:32 IMX6 crond[466]: time disparity of 24780553 minutes detected
24780553 minutes = ~47 years so it's detected 1970 (more than likely 01 01 1970).
So if the system clock was set at 17:26:36 how come at 17:27:32 it found a major difference. I thought it might be because of /etc/adjtime but that does not exist.
Everything is fine after that, just curious what might be causing it. Could it just be a timing issue on ntp?
What version of LE are you using? If LE 7.95.x then it's Kodi 17 - read the section 2.8.4 for the correct "cache" format.