All Windows versions since Vista should use SMB2 natively.
Posts by chewitt
-
-
No idea as I don't use it. You'll also need to check with one of the S912 image creators to see if they build it in their repo.
-
It's probably worthwhile pointing out there is no single config.ini file for our distro, so even if TFTP did work it's still not going to be the magic thing that configures lots of boxes for you.
-
NAS boxes sit in the network, the Android/LE box accesses over Ethernet (ideally) or a good wireless connection (less good).
-
Any idea if this will work?
MX10 - Android 7.1.2 RK3328 4GB DDR4 32GB eMMC KODI 17.4 4K HDR TV BOX 802.1.1 b/g/n WIFI LAN VP9 HDMI USB3.0
Not right now. However, the lead developer for our current RK work is also the lead developer for OpenPHT so I'd expect it to get some love at some point in the future. No schedule though

-
LibreELEC.tv/package.mk at libreelec-8.2 · LibreELEC/LibreELEC.tv · GitHub
Master branch builds with pre-Alpha Kodi Leia and newer ffmpeg are in circulation for most hardwares. Go test.
-
The only other thing I can suggest is trying LE on some other kind of hardware which might prove that the crappy old 3.14 kernel that's used on Amlogic boxes is at fault. It's a long shot though. I wouldn't personally buy more/newer drives. I'd get a NAS and put everything in the network where life is easier and fewer cables are required.
-
LibreELEC.tv/linux.arm.conf at master · LibreELEC/LibreELEC.tv · GitHub
^ the kernel has the driver enabled
-
Now that you are on 8.2.1 there is a manual update function in LE settings; updates can be done from the GUI.
-
Did you set legacy security (not just SMB1)? .. the reason that option was added in 8.2.2 was that we had reports of ASUS routers could not handle NTLMv2 and this option forces NTLMv1. Someone reported that the latest firmwares still contained ancient versions of Samba.
-
Code
Display More[Unit] Description=Create alias IP addresses After=connman-wait-for-network.service Requires=connman-wait-for-network.service [Service] Type=oneshot ExecStart=/sbin/ifconfig eth0 add 192.168.178.18 [Install] WantedBy=multi-user.targetSave ^ that to /storage/.config/system.d/ip-alias.service and run "systemctl enable /storage/.config/system.d/ip-alias.service" and cross fingers.
From: ConnMan, need to add secondary and third IPv4 addresses - Raspberry Pi - OSMC Forums
-
Our build-system compiles its own toolchain.
-
All prior issues that I've seen where devices mount under Windows but not Linux have either been unclean dismounts from Windows or the result of low quality firmware in the USB > SATA interfaces of the drive caddies. Windows blindly accepts whatever geometry is reported and attempts to mount the device. Linux validates what's reported, and if the data was bogus the validation fails and the drive is not mounted. That normally results in a load of error messages in the system log to let you know something is up though.
Can you swap a 'bad' drive to a 'good' caddy to see if things work?
-
Run the 7.0 version, enable SSH, login, then run:
You will need approx. 2.5x the size of the update file to be free for an update to work. If you need to clear space, remove old packages from /storage/.kodi/addons/packages and clear /storage/.kodi/temp
-
We already support PXE netboot. I wouldn't describe it as a popular option, but there are a niche group who use it, mostly on RPi hardware.
-
If you post a pastebin it will be dynamically loaded into the page in a windowed container. This saves the forum staff having to go visit another website to look at things.
-
In order of question asked, Yes, no, and no.
-
Except for a link to pre-installed micro SD cards on the Pi downloads page (which exists solely to stop people asking where to get them, and earns the project about £40/year in affiliate income) and a donation of some hosting credit from DigitalOcean, this project is entirely funded through end-user donations and deliberately has no commercial sponsors. None. The project has clearly stated non-profit objectives and since inception we have refused commercial partnerships to ensure the project remains free from those influences - a lesson learned from OE.
In the near future our approach to sponsors need to change. Why? .. because to increase the amount of Amlogic (and Rockchip, and eventually Allwinner) hardware that we publish images for, our hosting and currently very limited jenkins/continuous-integration infrastructure needs to expand. This costs real-world $$$ and the current annual levels of user-donations will not cover the projected expenses. We also need to plan and adapt the code of our build-system to permit greater levels of automation and test. It's really a HUGE and grown-up effort for the project, and it requires contributors to step-up and do some boring stuff for the general good instead of focussing on personal interests like hardware-hacking their latest device. We would also like to send people to FOSS events like FOSDEM and Embedded Linux Conference; to represent the project and meet the community peers who we collaborate with and have the "over a beer" conversations that result in relationships that help to move the project forwards. None of that is for free, and since money is involved there needs to be people who manage the money and people who have oversight to ensure responsible governance and avoid misuse. You perceive that to be 'corporate' behaviour. We (in particular those who come from OE which had zero transparency on these things) see it as simple common sense.
Our goal is (always has been, and will remain) to support much more hardware. However, aside from the functional things mentioned above which are holding that goal back, we also need to consider our name/reputation and that of Kodi and the rules of their trademark. We choose not to endorse and promote manufacturers who wallpaper our forum with advertorial postings for their products. We choose not to work with Android box vendors who ship "fully loaded" piracy devices that harm Kodi. We choose not to work with cheap manufacturers who provide terrible support for low-quality hardware and expect us to provide free support and software in return for a couple of samples and the opportunity to put their logo on our download page. In fact many of our contributors purchase their own hardware (or allow the project to buy) to avoid feeling beholden to a manufacturer because they accepted something for free. This position does sadly narrow the options on who to work with a bit, and the approach where we have bona-fide vendors like WeTek/HK having 'official' releases causes a problem because everyone else wants to be official too. This has to change in the near future (we completely agree on this!) but how that change happens is something to be discussed. How it is done will not be my or any other one persons decision. It will be a team decision. The first of many internal discussions to talk about some of these topics takes place tonight. However it's a complex topic, and a revision of our approach requires consensus. It will not be a quick process.
We have repeatedly tried to explain some of this to you, but you have repeatedly refused to believe or even listen to the explanations given. In the literal sense of the word you are unreasonable, i.e. "someone who cannot be reasoned with" and your views appear to be immovable. This inability to acknowledge actual facts or the general consensus view of basically everyone else in the wider team, many of whom have been contributing to LE (and OE before) for years not just a couple of months, is why people are increasingly tired and less accepting of your demands.
For the record, we know our audience. Your personal perception of Raspberry Pi being irrelevant to the future is not shared by the wider team or the 150,000+ existing LE pi users, and the future of LE (and Kodi on Linux overall) is very ARM based. We are proud of the contribution we make to the pi community and look forward to it continuing long into the future. There is also a considerable ongoing effort to solve some deep structural problems that have held Kodi-on-Linux back for a long time. LE contributors are leading this effort, and Amlogic (and Rockchip, and Allwinner, and Raspberry Pi) will benefit massively from the core architecture/performance work we are doing. However "Rome wasn't built in a day" and this will take patient months of collaborative effort. I place emphasis on the word patient.
I'm going to ask publicly that you rename the LibreELEC-AML github org to Community-LE or AML-Community or something else of your choosing that does not have LibreELEC as the main element of its name. Its appearance has caused some confusion with a couple of potential partners we are having tentative but positive conversations with. We have absolutely no issue with you running your own community development org. We do have an issue if that org portrays itself to be LE, or is easily confused for something official.
I will also publicly offer again, that If you would like to actually talk about things (Skype or similar) and resolve some of the misunderstandings that you have about how our project operates and the status-quo of certain things, you have my personal contact details and are welcome to reach out at any time.