Posts by chewitt

    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.

    Save ^ 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

    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:

    Code
    cd /storage/.update
    wget http://releases.libreelec.tv/LibreELEC-RPi.arm-8.2.2.tar
    reboot

    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

    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.

    I'm unaware of an issue with manual update being ignored so I'd suspect a person vs. fast internet timing issue. The default is auto-update and the OS update image for iMX6 is small so if you have a fast connection the settings add-on has probably polled for updates and downloaded the update to /storage/.update by the time the first-run wizard has completed and you go into LE settings to disable updates.

    We are aware of an issue with black screens on official iMX6 releases that use a 4.4 kernel. It's never been pinned down but affects a small minority of users. It's possible to use LibreELEC-imx6.arm-8.2.1-3.14-sr.img.gz from vpeter which uses an older 3.14 kernel (which has other issues, but the black screen is not one of them.

    If you install 8.2.2 directly it will not update as there a no more 8.2 releases planned. I suspect you will still see a black screen on reboot though. It is not possible to disable 'kernel' updates as the OS is packaged as single unit of kernel and system.