Posts by chewitt

Quote from deFRAGer

I think the SOC in this device is a Amlogic S905X4

There is no usable upstream support for S905X4 devices at this time, so an LE image is not possible. You can probably put CE on it, but that's a question for their forum.

using Handbrake to rip the ISO to file/files normally always works out quicker

You need to restore vendor u-boot to the box so we can hook it and run from SD/USB media. We do not support running LE from eMMC storage unless the board/box has upstream u-boot support - then we can overwrite eMMC with a full image that includes upstream u-boot. Your T95M does not have upstream u-boot support.

Quote from PaJoe

Is there a recommended kit with all the required hardware to set up a RPi5 running Libreelec?

Nope. Just look for board + official PSU + official HDMI cable + any case (we loathe Argon cases but whatever you like) + wireless remote + 16GB SD card. Any decent Pi board retailer will have all the bits.

There's no change to HEVC content (100% the same) but in my experience RPi5 will also handle a fair amount of software decoded VP9/AV1 content at 4K30 ish resolutions (doesn't have to be HDR) which extends the reach of e.g. YouTube. Plus some 10-bit H264 media that wasn't possible before now plays (also software decoded). The CPU in an RPi5 is probably on-par with an older i5 CPU; although storage/IO will be a little ahead on the Intel box. The difference in CPU grunt RPi5 has over RPi4 is noticeable.

Perhaps trash the latest DB versions (or rename them out of the way) and allow Kodi to upgrade again?

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.