Posts by chewitt

ifconfig wlan0 down && ifconfig wlan0 up

That ^ will bounce the wlan0 interface and thus force the interface to be reconfigured.

2025-08-27 17:55:57.951 T:823      info <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2025-08-27 17:55:57.963 T:823      info <general>: CAESinkALSA::Initialize - Opened device "default"

The logs are full of this ^ which indicates trying to open the 'default' audio device which is often/normally mapped to some kind of Analogue audio output.

2025-08-27 17:55:49.327 T:822      info <general>:     Device 3
2025-08-27 17:55:49.327 T:822      info <general>:         m_deviceName      : hdmi:CARD=Audio,DEV=0
2025-08-27 17:55:49.327 T:822      info <general>:         m_displayName     : Intel HDMI/DP LPE Audio
2025-08-27 17:55:49.327 T:822      info <general>:         m_displayNameExtra: TSB 55UHD_LCD_TV on HDMI #0
2025-08-27 17:55:49.327 T:822      info <general>:         m_deviceType      : AE_DEVTYPE_HDMI
2025-08-27 17:55:49.327 T:822      info <general>:         m_channels        : FL, FR, BL, BR, FC, LFE, SL, SR

The device with TSB 55UHD_LCD_TV name looks to be the Toshiba TV (on an HDMI connection).

So, have you selected the correct HDMI device in Kodi audio settings?

There is currently no mainline Linux kernel driver for the YT8601 chipset. There was a submission of patches to add support back in February: https://patchwork.kernel.org/project/netdev…2A&archive=both but there are quite a few comments to be addressed in the v2 series and there has been no v3 submission that I can see since then.

I'd be happy to cherry-pick patches for something that looks like it's nearing a mergeable state (as we can drop them in the near future once merge happens) but the v2 submission looks to be some way off that.

There are also some 'vendor' drivers that can be found on GitHub, but we have no interest in packaging out-of-tree drivers these days (the kernel patches would be preferrable).

I'd suggest a USB Ethernet adapter for now, or use WiFi (assuming the box has that and it works), or returning the box for something that has an upstream supported NIC.

Update to 12.2 or a 13 nightly and use the newer Tvheadend 4.3 release there. Check again.

NB: Please avoid copy/pasting AI content in posts. It's always complete BS.

Images are updated with u-boot 2025.10-rc3 to pull in Kwiboo changes for RK3576 boards. In theory no changes for older boards but you never know.

Quote from kelv

Initial boot of 12.90.1 on the rock-4c-plus looked good however no sound devices were picked up by alsa (13.0-nightly has functional sound).

Please put Kodi in debug mode then reboot and run "pastekodi" and share the URL so I can check for issues.

Quote from PANiCnz

For a RK3399 board how do these images differ from the standard nightly's? More or less features? or much the same?

Either way will give it a go on a Rock 4C+.

There should be no real-world difference as we're still using the same overly-large kernel/u-boot/ffmpeg patchsets. To long-term reduce maintenance effort I've merged all the kernel configs though, so it's possible there are some missing drivers.

Drivers need to be included at image creation/compile time. You cannot install or add them afterwards. If you can tell us the specific kernel modules that need to be enabled, we can add them to future images.

Fork my amlogic-6.16.y branch on GitHub then checkout a branch for your change, and then add your device tree file to arch/arm64/boot/dts/amlogic/ with a matching entry in the Makefile. Commit the change to your branch and then generate a patch with “git format-patch HEAD~1” and then rename from 0001-* to 9999-* and copy the patch file to projects/Amlogic/devices/AMLGX/patches/linux/ .. then rebuild the image and it should be compiled. If there are issues compile will fail with line/char references to the first failing problem. Note that you will not be able to just reuse a dts from CE as their kernels are diverged from upstream.

Go look at the pinned thread that I posted a couple of days ago. I’m not particularly interested in critique of media capabilities as those are known/understood, but it’s always nice to know that boards boot and don’t exhibit odd behaviours.

Quote from Elicity

Setting "PRIME RENDERING" to "EGL" solved this issue

EGL rendering is always a workaround not a solution, as it's not as efficient as DRMPRIME rendering. Interesting to know that it has impact though. DRMPRIME is the correct configuration to be using (in the long-term).

I forget whether the SMB chunk size changes are in K21 or K22, but to keep things simple use an LE13 (K22) nightly and experiment with the settings a little. You can force SMB v2 (2.0) vs. 'v2 and Large MTU' (2.1+ and 3.0) which might help. You can also force the client to use a larger or smaller chunk size; the default should work for most configurations, but there are exceptions.

Also see if Samba on the router can run in debug mode or can create enhanced logging? - In client/server relationships there are two sides that can have issues, and the kernel splat shows the router having problems. No idea whether it's a related issue or not.

The workaround would be to locally mount the remote SMB shares from the LE device using system.d mount files and then use the local mount points for your Kodi sources. This has the advantage of allowing you to create an SMBv1 connection to the router, and a separate SMBv2/3 connection to Win10, whereas the Kodi SMB client forces you to use the same config for all connections it makes.

See: https://wiki.libreelec.tv/how-to/mount_network_share

Elicity I've picked the patches for R6C. If you update using the RK3588 .tar file in my test share HDMI audio should work now?

Hard to tell what the issue might be, but ..

a) Use the Generic image not Generic-Legacy (unless you like watching HDR movies with washed out colours)

b) Read this and use the settings recommendations: https://wiki.libreelec.tv/configuration/4k-hdr

c) Fix your sources and Library so the SMB paths are correct (most are not accessible).

Any better?

Pause = You're in the middle of something and the system is still in use (so dim or show the screensaver)

Ended = You're done with it and the system is not being used (so turn the screen off)

There is a "Turn Off" screensaver in the Kodi repo. Install that as your screensaver and use the screensaver when paused.

ozarks I've updated the first post with info on media capabilities; VP9 is known and possibly a partial leak of RK3399 capabilities to the newer SOC, it's been flagged to Collabora. Regarding OPi5 and USB-C, if you can point me to patches on a mailing list I can pick them, but I don't think I see anything for that board. Or if you can figure out the patch (there is maybe prior art for the Rock5 boards) I can send the patch upstream on your behalf.

Correct, the zero-copy video pipeline (and no desktop environment) arrangement used in LE10+ doesn't allow for software-copying video data to anything so VNC and Ambilight installs aren't possible. External (hardware based) KVM devices will still work as those have no dependency on software internals.

I've pushed Rockhip images based on the RK356X/RK3576/RK3588 enablement PR: https://github.com/LibreELEC/LibreELEC.tv/pull/10420 to my test share.

Download here: https://chewitt.libreelec.tv/testing/

Images are versioned 12.90.1 in premature preparation for an LE13 alpha1 release. Don't get too excited at the version; there are no timescales and it's just a number. I use static versioning because it makes download URL's predicatable vs. having random githashes in filenames. If I push updated images to my test share the date/time of the image changes, not the version number.

Images are experimental "minimum viable product" not "finished product" state with 15+ different kernel patchsets (some merged, most are in-flight). There is huge scope for bugs and issues. You should expect to find some problems.

Media capabilities: H264 and HEVC should work. 4K modes should work, but there is no HDR and I don’t expect this to be added in the short-term. VP9 is software decoded at 1080p but hardware decoded at 4K (which is a bug as it should be software decoded) so 4K currently fails. AV1 is software decoded; the kernel driver exists but the corresponding FFMpeg hwaccel has not been written yet.

CEC should work although I never test this myself as too many identical devices are connected to the AVR and it gets confused.

HDMI audio is limited to PCM output. There is no pass-through and I have no idea what is missing or needed to enable that.

Feedback on issues related to distro packaging and specific boards (boot issues, missing hardware etc.) is useful. Feedback that includes fixes is particularly welcomed. If you want to be a "tester" posting "H264 working, HEVC working" levels of detail each time I post an update please keep quiet. The core image has already been through basic sanity testing and we have general knowledge of what works (and media capabilities are still very much work-in-progress) so that kind of feedback is noise and quickly becomes annoying. Of course, if you have technical knowledge on kernel and codec development we are keen to have your meaningful feedback!

p.s. If for any reason you need to share a log file, please use the built-in paste function or upload to pastebin.com and then share the URL generated. If you attach files to your post do not expect me to look at them.

Enjoy

NTFS support has come a long way in recent times but we still see issues (similar to what you describe) reported with the in-kernel drivers. You can also install the older NTFS-3G driver which runs via FUSE (so a lot slower) which might be more reliable.

If you want to eliminate the shenanigans do a rolling reformat to a native Linux filesystme like EXT4 or XFS. My personal preference is EXT4 as this allows filesystem shrinking in the event you ever need to juggle partitions (XFS only allows expansion) but that's not a frequent requirement for a media box.

Better still, shuck the drives into a Synology NAS case and avoid all those cables attaching USB drives. The ease of use and features and proper hardware design are worth the $$.