Difficult to say, as this seems to be more of an issue with your clients/network configuration (possibly software and/or hardware) as we're not able to reproduce. The current version of Samba Server in 8.2 supports 4GB+ without any issue. I use Windows 7 and don't have any problems with 2GB+ files, and we know a lot of people use Windows 10 (even Macs) and we don't see similar issues being reported. So I'm scratching my head trying to think what the cause might be, but I'm fairly confident the issue is not with the LibreELEC Samba server.
Posts by milhouse
-
-
Boot with the device connected, try to use it, then upload your dmesg and lsmod to a pastebin site and post the links.
-
Yes, 8.0 is using Samba 3.6.25 while 8.2 uses Samba 4.6.x.
When you say that you've "tried SMB2/3, SMB1", can you confirm you are changing both the min/max protocol in LibreELEC Settings > Services (and not values in Settings > Services > SMB Client which affects only the Kodi client and not the local Samba Server)?
-
Nope, sprunge.us is still down.
his.dudeness Try an LE9 nightly as the latest #0125 build includes a change which may improve smb:// performance.
-
is there a way to get the SMB chunk size fixed in the latest stable 8.2.3 LibreELEC, as the 9.0 is as expected... causing me some other troubles...
No, but we're aware of the issue and the fix being used by RPi 9.0 builds, and will consider it for any future 8.2.x update.
-
This means that in libreelec 9 there is NO apollo lake / kaby lake 4K HDR10 support so far?
It is quite hard to get a reliable answer on that, yesterday it sounded like it is supported.
Correct - not (currently) supported. A number of components need to be updated to support HDR: Kodi, ffmpeg, gpu drivers, kernel. When this support will appear nobody really knows as we're dependent on the upstream maintainers and their priorities/agendas, but it will appear eventually (and will hopefully support your Intel hardware before it is obsolete - Linux does seem to be a low priority for Intel these days).
-
how to test that? how to compile / install such al build
LE 9/Kodi 18 test builds for Generic are here. You can upgrade by dropping the LE9 tar file in your Upgrade Samba share. Downgrade back to 8.2.3 by performing a manual update in the LibreELEC Settings add-on.
-
Can't see your logs as the server is down - can you re-upload to ix.io? It would also be worth uploading "journalctl -a | pastebinit".
since the upgrade from LE 8.0 to LE 8.2.1 it takes literally 3 minutes to open my cifs shares.
Do you really mean CIFS (which implies OS mounts) or Samba mounts (smb://)?
-
This is strange, because those symbols never appeared on early version of libreelec.
More recent firmware optimisations now have the CPU/GPU working harder when decoding H265 which can result in increased power consumption while also resulting in reduced temperature (as some of the work that was previously performed by the ARM cores is now done instead by the GPU). This would explain the change you have observed from over temperature (red thermometer) to under-voltage (yellow lightning bolt).
It sounds like your system is marginal in terms of both cooling and power supply.
FLIRC cases are good at cooling with their built-in heatsink, and the official Raspberry Pi power supply avoids any risk of under-voltage.
-
epias is yours also an Apollo Lake NUC?
With a NUC6i5SYH (Skylake i5) and either 4.14.14 or 4.15-rc8 I'm able to resume from suspend with a USB keyboard (press any key), or RC6 CIR (only the "power on" code works - all other remote buttons are ignored). I'm on WiFi not wired so can't test WOL.
My remote is a Logitech Harmony One using device profile "IntelD54250WYK".
Not sure why Apollo Lake would behave differently to Skylake, but most likely Intel spotted an opportunity to save a cent on their overpriced CPUs and as a result introduced yet another bug or unsupported feature.
-
The only other option at this time (that I can suggest) is to try another test build based on the 4.15.0 kernel (due for official release any day now). For example this build based on 4.15-rc8. I'm aware of one kernel issue in 4.14.y that is addressed by 4.15-rc, there may be others.
-
temp_limit=80
This shouldn't be necessary, as it just means your Pi will throttle the CPU if it reaches a temperature of 80C instead of the higher default temperature limit which is 85C.
I would also recommend using "gpu_freq=500" instead of "core_freq=500".
-
Apollo Lake was a fairly new CPU at the time of the 4.11.12 kernel in LibreELEC 8.2.x and support for the latest CPUs may now be a problem. Unfortunately this kernel is unlikely to receive significant changes in any possible future 8.2.x release so if the Apollo Lake suspend/resume issue is a kernel shortcoming then it is unlikely to be addressed by any future 8.2.x release.
I would suggest trying LE9.0/Kodi 18 test builds which are based on 4.14.14 (at the time of writing) - these have no suspend/resume issues when testing my i5 Skylake.
-
and right now I'm newly setting up LibreElec as a single boot system since I didn't like the peculiarities of a multi boot system with berryboot (no automatic updates, some stuff more complicated).
Bertel very wise move indeed!
For anyone else currently using Berryboot with LibreELEC:
Do NOT use Berryboot as Berryboot is not supported by LibreELEC!
Aside from the inability to upgrade using the standard LibreELEC upgrade procedure, the main reason why Berryboot is not supported by LibreELEC is that Berryboot replaces critical LibreELEC software components with components sourced from random non-LibreELEC operating systems that do not perform to the same standard or in ways expected/required by LibreELEC. It's a miracle LibreELEC with Berryboot works at all, to be honest, until it doesn't of course, and then the LibreELEC developers have to pick up the pieces caused by Berryboot.
The github instructions to "update" a Berryboot installation by copying only the SYSTEM file do not address the fact that LibreELEC will still be missing the matching LibreELEC kernel, firmware, kernel module and device tree files that are shipped in a normal/official LibreELEC release (these files are all removed by Berryboot in their "releases").
Users of Berryboot systems will have problems that nobody else can reproduce because their Frankenstein Berryboot system resembles absolutely nothing created or released by LibreELEC and is just a random mess of mismatched components.
Anyone using Berryboot should make a backup of their data using the LibreELEC Backup tool, re-write their SD card using the official LibreELEC 8.2.3 img.gz (latest version at time of writing) downloaded from libreelec.tv (and most definitely not the unrecognisable version of "LibreELEC" from Berryboot that should not be distributed as though it were an official LE release), and then restore their data from backup.
If you must use a boot manager then both NOOBS and PINN are supported by LibreELEC. But not Berryboot.
-
Ah. Good spot, thanks!
-
Somehow your mount unit has a dependency on itself?
From an RPi2 with LibreELEC 8.2.2 using your mount (only changes being the server ip address and share to match my own FreeNAS server, and vers=2.0 because my FreeNAS 8.3.x server only supports SMB2_00 not SMB2_10):
Code
Display Moreneil@nm-linux:~/projects$ ssh root@rpi22 ############################################## # LibreELEC # # https://libreelec.tv # ############################################## LibreELEC (official): 8.2.2 (RPi2.arm) rpi22:~ # mkdir -p /storage/ServerFolders/Videos rpi22:~/.config/system.d # ls -la /storage/ServerFolders/Videos total 8 drwxr-xr-x 2 root root 4096 Jan 21 16:25 . drwxr-xr-x 3 root root 4096 Jan 21 16:25 .. rpi22:~ # cd /storage/.config/system.d rpi22:~/.config/system.d # cat storage-ServerFolders-Videos.mount [Unit] Description=cifs mount script Requires=network-online.service After=network-online.service Before=kodi.service [Mount] What=//192.168.0.3/data Where=/storage/ServerFolders/Videos Options=username=user,password=password,rw,vers=2.0 Type=cifs [Install] WantedBy=multi-user.target rpi22:~/.config/system.d # systemctl enable storage-ServerFolders-Videos.mount Created symlink /storage/.config/system.d/multi-user.target.wants/storage-ServerFolders-Videos.mount → /storage/.config/system.d/storage-ServerFolders-Videos.mount. rpi22:~/.config/system.d # systemctl list-dependencies storage-ServerFolders-Videos.mount storage-ServerFolders-Videos.mount ● ├─network-online.service ● ├─system.slice ● └─network-online.target ● └─kodi-waitonnetwork.service rpi22:~/.config/system.d # systemctl start storage-ServerFolders-Videos.mount rpi22:~/.config/system.d # ls -la /storage/ServerFolders/Videos | head -5 total 8783876 drwxr-xr-x 2 root root 0 Dec 12 03:44 . drwxr-xr-x 3 root root 4096 Jan 21 16:25 .. -rwxr-xr-x 1 root root 10396 Dec 13 19:00 .bash_aliases drwxr-xr-x 2 root root 0 Jul 6 2015 .pcacheMaybe try disabling and re-enabling the mount, and check you don't have any unexpected junk/sym links in /storage/.config/systemd.
-
Sounds like there's something wrong with your NUC as it shouldn't be freezing. What CPU is it?
We recently added some fixes for Baytrail freezes (during idle, though, not playback) which are now in LibreELEC 8.2.3 (released about 5 minutes ago) so if you have Baytrail hardware it might help you.
Other than that, first thing I'd check is that the RAM is OK (memtest86+, leave it running for several hours).
-
Your unit works as expected in official LE 8.2.2.
What build are you using? Can you provide a complete "journalctl -a"? Maybe you have additional services that are now conflicting.
