Posts by chewitt

Quote from Shoog

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.

Quote from nsauro

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

Looks like the package is expecting to cross-compile for arm64 and you're trying to build for arm. It probably has hardcoded references to the arm64 toolchain which need to be revised.

Look in /storage/.ssh .. it appears we moved it since the last time I looked (about 5-years ago)

LE has two partitions; boot files (visible in /flash) and persistent storage (visible in /storage) and you need to make a 'dd' image of the entire card to capture both. However, it is significantly quicker to use the backup/restore functions in the LE settings addon as this only saves the 1-2GB of data in /storage/.cache /storage/.config and /storage/.kodi vs the 8/16GB on a typical SD card. Users frequently obsess over making an 'identical' clone but this really is not important or essential. SSH config lives in /storage/.cache/.ssh.