Posts by chewitt

If you like hardware launched in 2017 .. it's great. I'd still prefer an RPi5

Kernel DRM doesn't see valid EDID data for the TV and falls back to some default resolutions. Kodi then configures itself based on what the kernel says the TV can do. I'd check/replace cables or change the socket the box is connected to. NB: The same image is showing everything fine here (on a VIM1, but that's irrelevant).

Quote from arcasys

mounting /dev/nbd0 fails with various error messages (dmesg)

And the errors are?

To figure out the specific change that altered behaviour you need to "git bisect" the changes in our GitHub repo between 11.0.2 and 11.0.4 or narrow the time range to a specific day using bisect-like testing of nightlies between the release dates. I have hunch the NFS session needed for the persistent system mount is disrupted/lost after initial boot and playback resulting in Kodi losing "local" access to media. To understand/prove that you'd need to capture/analyse PCAP files, but they will be large (I'm not volunteering).

Some thoughts: If you accessed media using the Kodi NFS client this expects connect/disconnect events to happen (whereas local media access does not) so that might prove more reliable than a system mount. I've also personally found SMB to be more reliable than NFS at accessing content remotely on my own hotel/remote device. These days I only use the native SMB client. That said, I also see too many issues with poor speeds in hotel networks so while I can access media over SMB from the NAS via a WireGuard tunnel to home; I mostly use the Plex add-on for Kodi to stream content from a Plex server running on the NAS. This only requires me to expose ports for Plex (so no WireGuard needed) and Plex can transcode content into a lower resolution (less bandwidth required) on-the-fly if the connection isn't running fast enough or I want to override/force the resolution.

NB: I'd also put "ip route add" commands into a systemd service so it can be scheduled more accurately than "sleep 20" after the WireGuard tunnel is established. I doubt that's involved in the problem you're seeing though.

There are many improvements in LE11/12 for RPi4/5 hardware so I would make a bit more effort. Have a read of this article which describes some general recommendations for better playback https://wiki.libreelec.tv/configuration/4k-hdr

Quote from pagi

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.

Quote from dmladenov

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

Quote from alfredxyz

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.

Quote from dmladenov

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.