Posts by chewitt

We stopped formally supporting ARM devices with < 1GB RAM with LE10 as our feeling was the codebase using the newer video pipeline has outgrown 512MB devices and 1GB was the minimum needed for a good user experience. There's been no attempt to actively prevent installs on 512MB devices and stats show some LE10 users have been using it, but it sounds like things finally tipped over the edge.

The issue is likely to be RAM footprint. You can save memory in a custom image rebuilding the kernel with fewer things enabled (and more use of =m than =y) and disabling services that might not be required; WiFi, BT, Samba, etc. and perhaps experimenting with ZRAM (there's a Pull Requst for that on GitHub). All of them are marginal gains but collectively they might accumulate enough to be meaningful.

The easier option is repurposing a Model B board with 1GB RAM.

2023-03-09 14:15:11.682 T:1194  warning <general>: Failed to get an OpenGL context supporting core profile 3.2, using legacy mode with reduced feature set
2023-03-09 14:15:11.765 T:1194     info <general>: Using visual 0x20
2023-03-09 14:15:11.796 T:1194     info <general>: VDPAU::CreateContext - creating decoder context
2023-03-09 14:15:11.799 T:1194     info <general>: vdp_device = 0x000000 vdp_st = 0x000001
2023-03-09 14:15:11.799 T:1194    error <general>: (VDPAU) unable to init VDPAU - vdp_st = 0x1.  Falling back.
2023-03-09 14:15:11.800 T:1194     info <general>: CRenderSystemGL::InitRenderSystem - Version: 2.1 Mesa 22.3.5, Major: 2, Minor: 1
2023-03-09 14:15:11.800 T:1194     info <general>: GL_VENDOR = Mesa Project
2023-03-09 14:15:11.800 T:1194     info <general>: GL_RENDERER = i915 (chipset: Pineview M)
2023-03-09 14:15:11.800 T:1194     info <general>: GL_VERSION = 2.1 Mesa 22.3.5
2023-03-09 14:15:11.800 T:1194     info <general>: GL_SHADING_LANGUAGE_VERSION = 1.20

The GPU fails to create the OpenGL surface needed for Kodi ^

CvH I'm wondering if this device requires the older i965 driver?

Quote

To set expectations, here’s the ‘No’ list:

- No support for updates from older LE releases (clean install is mandatory)
- No support for internal eMMC install except WeTek Hub/Play2 and SBC boards
- No support for SSV6501 and S908CS WiFi chips
- No drivers for in-box DVB tuners
- No hardware deinterlacing
- No HDR to SDR tonemapping
- No formal support for newer S905X2/D2/Y2, S905X3, S922X, A311D devices (read below)

Display More

I added that ^ to the release announcement for LE 11.x final (and all beta releases). In the same text I also tell people to read the instructions in the wiki as boot processes have changed from older releases (things like needing to set dtb names). I also state that these images might not meet everyone's requirements, and it seems you are one of those users, so please continue to use LE 9.x .. or Android .. or anything else.

Quote from lokonai

"IPTV Recorder error - Check the log for more details"

So I only see one solution: Find a Kodi 19 Leia Libreelec image for dreambox one or older....can anyone help me?

There are no images with K19 for Amlogic.

Follow the add-ons advice and share the log.

echo 'option iwlwifi amsdu_size=3' > /storage/.config/modprobe.d/iwlwifi.conf
reboot

Login over SSH and run the command ^ and it will create the file, then reboot.

I'm not sure there will be much add-on breakage with Omega. Kodi devs are generally running their own code so anything from the Kodi repo normally works fine, and there are no major API differences between Nexus/Omega (so far) to cause disruption with other add-ons; the Py2 to Py3 changes are long done and settled now. One change that will happen in LE12 is a switch from arm to aarch64 userspace as 64-bit widevine libs have finally appeared.

On the kernel side, if there's anything notable to backport from newer kernels to 6.1.y then it can be done. I plan to send at least one more bump for LE 11.0.1 to resolve the "pink line" seen on S912 boards when scaling SD media to 1080p. I'm not expecting much progress to happen on hardware decoders in the near future though.

NB: I will probably close this thread and fork a new one for K21 images soon. I do need to move the kernel codebase forwards to drop patches and ensure I'm not sitting on too much technical debt.

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-11.0.0.tar
reboot

^ SSH commands

Quote from Spielmops

Why does this download-file exist? And why does a SD-card with that file (for SD-card) not boot?

Running LE11 from the internal emmc requires upstream u-boot; which that image contains. It cannot boot the box from SD card because vendor u-boot doesn't support the extlinux boot files needed for upstream u-boot. so you boot the box image (so emmc is not in-use) and then download and install the board image (that image) to emmc. Others have grasped that and succesfully installed. You haven't, but that's not really something I can solve. Your weird screen issue is not reported anywhere before so it's probably rare or something odd and unique about your environment. And the AMLGX image is not perfect, nor advertised as being perfect. But it works good-enough for me and my very typical media collection, and likely others have a similar experience (active install numbers are increasing). So sorry it's not for you, but we can't please everyone. I suggest you stick with 9.0.2 or bin the device or run Android or whatever you prefer.

Your "serious flaw" is known because it's been seen before; maybe 4-5 times since public beta testing started. In that period there are ~20,000 installs on a wide range of hardware so it's definitely niche and not worth holding up the 11.0 release for. It's not been seen by anyone on staff or anyone in our ecosystem with a clue about triage/test .. and since we aren't really sure where the issue resides it's not clear what info might be required (but we do know the usual Kodi and boot logs will not show anything interesting). In time there'll probably be a Eureka moment and it'll be resolved. Until then ..

The fix is not done "in GBM" .. the fix is done in the RPi video driver, and the Intel driver, and the AMD driver, and the Amlogic driver, and the Rockchip driver, and the Allwinner driver. That's rather a lot of very complicated low-level driver work and the reason why it hasn't already been done and isn't likely to happen. The possibility of an RPi4 only fix is marginally higher, because at least one of the RPi Foundation devs has a personal interest in 3D support. However, progress probably requires him to have lots of rainy-days with low workload in the office or a long convalesence at home with too much free time and an itch to scratch; neither scenario is that likely.

Source too slow means a lack of bandwidth in the network or the NAS/Server device hosting files being unable to stream the file fast enough. I see this occasionally with very large ISO rips that I've made (70-80GB size) but it clears after 5-10 seconds. It can also show up if the server is trying to transcode content on the fly and not quite keeping up .. which I occasionally see when using Plex as the back-end server (with the Plex client add-on in Kodi).

The "hdmi_enable_4kp60" option is rarely needed and causes much higher current draw on the PSU and will need an HDMI cable certified for 4K60. Cheap(er) cables will often give blank screens. Under-spec PSUs can do the same. Practically all media is [email protected] or 4K30, only GoPro files and content people have deliberately encoded in 4K60 requires it. Most users do not need it (which is why it's forced as a default).

I don't use DLNA and have never used Jellyfin, but I occasionally use Plex and it works fine. If you are using WiFi .. that's probably the cause of all playback issues. Connect a cable and test again. WiFi is rubbish for streaming media and that's a near-universal rule and nothing specific to RPi4, although RPi4 having no external antenna and being often installed in a nice shiny metal case doesn't help.

On paper RPi4 is missing some hardware codecs and has less CPU grunt in comparison to the Intel device. In practice the upstream support for older Intel GPUs has some rough edges and the initial HDR support available in LE 11.0 is less complete than RPi4 currently has, and the missing codecs are often non-criticial, e.g. no VP9 just means YouTube uses H264 instead. I'm not sure a 5-year old 7th Gen Intel device would tempt me too much. I'm also a believer in "if it works, don't fix it" so unless there's a really compelling argument I'd stick with the RPi4.

Quote from LybsterKodi

I'm asking because I'd hate to export the database, transfer file to a new disk, reload everything and loose the adjustments.

As long as you aren't changing the 'sources' configuration (so paths remain the same) you can simply copy/move the latest DB files to the new install. There's no need to export and reimport the DB, and this preserves all settings saved to the DB.

The LE installer installs syslinux as the bootloader and creates two EXT4 partitions in a GPT scheme (1= 512MB and 2 = remaining space). Once in a while we see BIOS that wants to see an MBR scheme with a FAT first partition, or that doesn't like syslinux but works fine with grub (which is what Ubuntu uses) and I'd make an educated guess it's the latter scenario. So boot into Ubuntu on a LiveUSB stick, create the partitions on the emmc storage, install grub and create the required boot/menu entry, and copy the SYSTEM/KERNEL files over to the first partition. That's all our installer does. NB: There are some grub files on our installer USB to crib the menu entry from, as we use grub for systems that need to have a 32-bit boot environment. It seems yours is 64-bit though, and we use syslinux for that.

Your WiFi passphrase is a passphrase not a key so entering it over and over won't achieve anything. This is probably something related to crypto in the kernel and the change to IWD. At the moment "it's a known problem" but how to triage/diagnose the issue is not known and there is no solution. To be continued..

It probably requires the RTL8189 WiFi driver which is not available in the upstream kernel and LE will not be adding the vendor driver to the core image; we have a long-standing policy of not adding more downstream drivers that typically break with every kernel bump. That said, the driver is currently included in my own fork: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar

I make no promises that the driver will remain in my images. If (as is normally the case) a kernel bump breaks it I will probably drop it.

I'm not aware that RK hardware supports 10-bit output at the moment.