in kodi in the settings I can't set in the white sheet set 4096x2160p 60.00hz why?
You probably haven't forced the RPi4 to support 4K60 modes in config.txt. The 4K60 modes are not enabled in RPi4 firmware by default, and to MatteN point most users have no need for them (the only media I see "in the wild" above 4K30 is test media).
Correct, dd is making a storage block level copy of the raw disk.
I'd ask that kind of question in the Kodi forums skinning section. It's not really an LE topic.
True "bricking" of the box requires physical hardware damage, but flashing an incompatible u-boot will leave the box in a software state which is challenging for most users to self-recover from. Amlogic silicon normally prioritises emmc boot; so flashing something that won't boot to emmc results in an endless boot-failure loop. UART cables aren't the solution; although they will allow you to see what's happening and confirm the endless loop. If we assume you don't have a special HDMI boot dongle or SDIO debug board the only way to stop emmc boot is shorting pins on the emmc chip to electrically disable it; thus allowing boot to progress to the next step which is checking for boot firmware on SD or USB media. Most Android recovery images won't fully boot from SD/USB media, but as long as you can get u-boot itself to run the device should then show up in Amlogic flashing tools again. You'll find more info on shorting emmc pins in other forums: flashing Android images to Android boxes isn't really a LibreELEC problem to solve.
I haven't booted LE11 images for some time. I suggest you use LE12 nightlies or images from my testing share.
For your convenience, the easiest way to boot from USB is through the Android update menu, point to the zipped autoscript file and click on Update button.
I'm not keen on cheap Android boxes in my network (too much weird activity from them; malware seeking new targets in some cases) so will be using an HDMI dongle that forces USB boot: https://github.com/superna9999/li…DMI-Boot-Dongle
Could you help me please with that?
On most boxes invoking recovery boot mode causes the box to search for autoscript files or simple boot.scr which we use to hook the boot process. If your Android 6 firmware erased that you'll need to connect uart cables to the board (soldering the uart pins if needed) to interrrupt u-boot and edit the environment to reinstate the required search behaviour. The bootscript content in https://github.com/LibreELEC/Libr…_autoscript.src should be what you need to add. I forget if you can edit the environment from Android .. it's years since I wasted any time on vendor kernel things.
I've removed the links. It's the same as the cheapest box I have available here 
EDIT: I've ordered one for $25, arriving this evening. It'll give me something to play with while resting legs next week (am running a marathon tomorrow morning).
There are some rough edges to NTFS support since we switched from NTFS-3G to in-kernel drivers with LE11. However that should only result in the mounted NTFS volume being marked "dirty" needing chkdsk.exe to clear the dirty state. We haven't seen reports where volumes or the underlying partition data have been trashed. Most partition schemes also maintain multiple copies of tables to prevent against total loss (or to at least make restore easier) so if those are also missing I'd be suspecting a more serious problem with the storage (favourites would be power and firmware issues): I note that LE deliberately doesn't support any form of software RAID so it must be done in hardware (which means RAID config is nothing to do with our software).
Partition data can be backed up with a script that uses "dd" to copy the first few MB of disk to a file. You then need to script that being sent off-box or stored on a separate storage device. You can automate script execution with cron or a systemd timer.
Have a read: https://wiki.libreelec.tv/hardware/amlogic
The images in my test share https://chewitt.libreelec.tv/testing/ have some additional Realtek drivers that are deliberately missing from official images.
So can we confirm that all p271 boxes are Mali 450-MP2 and should use meson-gxl-s905l-p271.dtb from your images ?
The current assumption is that p271 is the "3" variant and p261 is the "2" variant, so I need to switch the numbering else p271 will try to use 3x Mali cores and everything will lock-up when the hardware probes. I'll let you know when that switch is done.
What does the case on your box look like? .. Amazon UAE has some cheap S905L devices so I might get one to run experiments on the audio problem. That needs to be resolved before I think about trying to upstream anything.
I have a hunch it's down to media type, as I don't see 'gaps' in playback with normal mp3 tracks but do occasionally hear them with WAV files (used for DTS albums) sometimes; more noticeably when tracks have large filesizes and/or when I ripped an album to a single large file and not individual tracks. I also have some badly ripped mp3's from the early 2000's that have legitimate silence in them (annoyingly).. it was a thing sometimes back then. Otherwise there's no setting for gapless playback, it's the default.
Have you enabled the service, i.e. "systemctl enable /storage/.config/system.d/add-route.service" ?
RPi5 has a power on/off button and the Flirc case (shipping soon) will be decent (and there are others). For sure it's not the perfect hardware for everyone's taste, but it has the best software support by noticeable margin and that's the most critical factor for daily-driver usage with LE/Kodi. NUC's started out as a solid piece of kit and their reputation is built on that, but in the last few years as Intel bred chipsets faster than people wrote drivers for them it's been less smooth sailing and the current experience does not live up to past reputation. I think some of the cheaper mini-PC devices devices that ship these days have promise, but I think software support needs to improve in multiple places before you'll see project staff singing their praises.
I've noticed some glitches playing things back but I haven't had time to investigate properly. I have a hunch this is related to Kodi rendering and not the codecs; though those definitely have their own issues too and that's what shows in the system log. Over time the surrounding kernel keeps moving forwards so the lack of codec maintenance means differences start to creep in, causing minor regressions until eventually something more fundamental breaks. There's an issue with buffers not being free'd which will cause the device to run out of memory over time, and there are other things too.
The other hardware device that isn't working correctly is the rtc chip, which doesn't report any time data. If the boxes use a coin cell batter that can be removed, remove it and it might show different log messages. If it's a soldered one that's not possible but the thought it that low/under voltage might results in bad or no values being readable.
Thanks for confirming WiFi works again.
There's nothing in the Kodi logs, which is one reason why we asked for "pastekodi" which also outputs the systemd log. You may also need to include the FTP server log (assuming there is one).
It'll be more work to create and maintain an add-on than to simply rebase the one-line/one-commit change to enable/include the package in a self-built image. The add-on would only work for your post-boot use-case whereas iscsi is more commonly used for early-boot things (albeit not within LE as I don't recall anyone complaining when we dropped it from the image).
