I'm looking for some help with this problem and appreciate any comments/corrective actions. Thanks
S802.arm updating to S802.arm is allowed as the project.arch matches. If you update to something else (S8X2.arm) the project.arch does not match so the update aborts. If you want to force the change; read the on-screen text for instructions.
No kodi debug log = No problem
The lspci output only proves the hardware powered on, it has no bearing on driver support for the hardware. The (broadcom) wl module contains a mixed GPL/proprietary license which taints the license status of the kernel (no longer pure GPL). It's irrelevant.
What driver is that card supposed to use?
Updates are performed by placing the .tar file in the .update folder. The img.gz files are for burning fresh SD/USB installs.
Shoog
Unless wrxtasy broke something in his releases we have supported .img.gz file updates since LE 7.0
Windows and Linux have fundamentally different approaches to drive mounting. Windows wants to ensure you can access your data so as long as there is 'a' valid disk scheme somewhere on the disk it will mount. Linux values integrity and will refuse to mount when issues are found.
If you have other storage devices; move the data off (via Win) and reformat the drive, copy the data back. Test for a while. If all is good it was nothing to worry about. If you see further issues it may be a physical issue with the drive and it's time for a replacement.
Please provide a Kodi debug log showing the install failures.
It's probably a shutdown problem. We wait patiently for Kodi to stop gracefully, but there's a timer running and if we time-out Kodi is killed and the system stopped. Kodi saves guisettings.xml on shutdown so if we have to kill the Kodi process you can get partially written xml, and on startup the malformed/incomplete xml is detected and replaced with default settings; hence the appearance of settings reverting or being lost. Add-ons are the main cause of delays to shutdown. Another possible reason is you're looking a media via an add-on, in which case it's the add-on authors responsibility to support persistent view states. I have a couple of legitimate add-ons that don't.
I've never spoken to anyone from Minix and I have zero knowledge of their roadmap. I have visibility of others' roadmaps though..
Separate the media that won't scrape into it's own source and the create .nfo files; set the source to use/scrape local data only and it won't waste time trying to obtain info from online sources. In some cases the other route is to register an account and add the movies to TMDB/TVDB so they scrape online correctly. I've done that for a bunch of foreign language films I have.
I'd guess that either the unknown device tree is wrong or there are no drivers for the unknown wireless chipset in the unsupported box.
Yes, but you need the Jun 16 build
Go test a current milhouse release to see if the issue is resolved in K18 .. nothing is going to be investigated or fixed on Krypton now. If the issue still exists submit a *debug* log that exhibits the problem. Non-debug logs aren't useful.
Attachment #1370318 for bug #1527231 is the proposed patch. What image do you need for testing?
ping milhouse
S905X2 and S905D2 devices are already in production. I'd expect to see S922 devices start appearing in Q3.
There is nothing in our standard image that would erase/remove those files on startup.
Hi, have got any news about LE on RK3328?
Still under active development. Still has some important things to code and get right before we do official releases. When there's major news we'll broadcast it 
The backup function in LE settings is just creating a standard .tar archive. To avoid all the unnecessary time and space issues of imaging the SD card just make a tar backup that includes the folders you need to backup. It's, really, not, hard.
K18 is still in an early alpha state so the whitelist function probably isn't fully developed. Perfection rarely comes at the first attempt
ping lrusak
