fstab uses kernel mounts not smbclient and in Ubuntu 16.04 this is probably SMB1 by default, but it also might not work with SMB3 (depends on what Ubuntu's kernel allows) so try adding vers=2.0, e.g.
mount -t cifs //10.19.64.3/Movies /media/OpenelecMovies -o vers=2.0,user=libreelec,pass=libreelecWorking?
run "lsmod" to list the kernel modules active .. but if is "wl" the older broadcom STA driver, we already ship this:
LibreELEC.tv/package.mk at libreelec-8.2 · LibreELEC/LibreELEC.tv · GitHub
so how it works on Ubuntu and not us is a mystery..
Please read the release notes
And what OS version is the Windows box?
This is a guess, but an educated one: I'm not sure LE 8.2 supports 32-bit boot devices (some CT devices are 64-bit but only support 32-bit boot) but LE 9.0 (development images) do - via grub, which is also what Ubuntu uses. Grab a current milhouse development build from the Kodi forum and use this to install so you have a working bootloader, then downgrade to the normal 8.2.0 release using the manual update function in the LE settings add-on, and then perform a hard reset to remove any stray Milhouse/Leia configuration bits. Make sense?
Look at the package.mk in GitHub .. I'm not able to check from current location, but since we predominantly use alsa for audio we probably don't compile mpd with pulse support?
It sounds like you have an older OE era install with 235MB(ish) boot partition? and the update file is more than 95% of the available space so the update gracefully aborts. If that's the case the quickest resolution is to do a backup > reinstall > restore as the reinstall will create a 512MB boot partition. The normal LE image is a little smaller so squeezes under the 5% free space requirement.
Tvheadend "client" is currently at 3.4.27.1 as per the Kodi Krypton repo: Commits · kodi-pvr/pvr.hts · GitHub
Tvheadend "server" is currently at 4.2.3-20 which is the latest (or close to latest) stable release. Anything with a 4.3 number is from the pre-alpha testing branch and should be treated with suspicion. If it works, great. If it doesn't work, not our problem.
It should be fine in Leia releases because we're still using the same Xorg based graphics stack and nvidia drivers. Right now it's unclear whether we will have nvidia support post-Leia but that's a longer story.. and nothing definite yet.
Current estimates on availability of a mainline kernel do not align with Kodi Leia schedules so Leia will need to use amcodec and the existing 3.10 and 3.14 kernels. That breathes a stay of execution on MX chipsets but it makes the decision to expend effort on generic kernels harder. There are benefits to unifying some of the community efforts further; IMHO too many community builders are "developing in the release branch" with a high rate of release iteration so providing a project for things to focus on will stabilise things. However, all work on the 3.10 and 3.14 kernels is ultimately "lipstick on a pig" as the second we have a viable mainline kernel we will drop support for anything that cannot run it. Right now S805 era boards will probably survive (no guarantee, but they have a lot of IP in common with S905 and newer) while MX based devices will bite the dust.
So it's possible, but much is in the hands of community builders agreeing to align their efforts. So far no PR's have been received on GitHub.
en:users:drivers:brcm80211 [Linux Wireless] <= states there are no Linux drivers for the BCM43231 chipset so I am interested to know which driver and version is reported in Ubuntu?
I'm asking about which LE image, e.g. Raspberry Pi or Generic? .. not the Apple stuff
It's worth experimenting with a current milhouse release. This bumps major components that impact performance/behaviour of Intel GPUs and also provides a codebase that is still in development; i.e. if there's a bug it can be triaged and fixed, whereas Krypton has not been touched for months and only receives occasional (simple) backports from Leia now.
if the 340.xx driver works, use it, problem solved
LE compiles OpenVPN for client use so it cannot be used as a server. I can also guarantee that PPTV will not be making a comeback.
The alsa configuration in Amlogic kernels is a hack, so don't expect things to work correctly. Things should improve once we move up to a mainline kernel from the 3.14 Android based crapfest we are currently stuck with. There is no schedule for that yet.. before you ask.
the options method is correct for persistence, but if there is no wireless regdom in the kernel it won't have any effect
HK provide their own version of wiringPi, which almost certainly means they have adjusted it to match the GPIO layout. I doubt the Pi add-on can be ported directly.