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.
Posts by chewitt
-
-
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 $$.
-
Zip or text, the issue is not the format but the extra clicking to download find open read .. vs. clicking a link. Sounds petty but do it 10,000 times and ..
-
See https://github.com/xbmc/xbmc/issu…ment-2541224018 - It is possible to compile a patched version of Kodi that forces the rotation permanently; the patch is in that thread (along with a load of AI generated how-to-compile BS that someone unhelpfully posted). It is not possible to dynamically change the rotation (the UI shows options, but they won't work).
-
LE uses alsa. Pulse is present and running but only used for BT output, unless you manually reconfigure it and then it's a layer on-top of alsa, so it won't solve anything (you only add to the layers of problem) if alsa isn't working.
Please share a proper debug log not snippets of what you think is revelant. You omitted all the stuff that's actually useful. Use the built-in log paste function (uploaded zip files are a pain in the rear).
-
-
Is it the same for le too?
IIRC the breakage occurred earlier than Linux 6.16 but there were no patches to be found anywhere when it occured and we waited a while before moving to drop the driver. As exorcising external drivers with no hope of ever moving upstream has been a long-term initiative, even if patches for 'wl' did appear now, we have no plans to reinstate support. Sadly the 'b43' driver is not in great shape either and we're a little surprised it's not been purged from the kernel due to its equally unmaintained state; hence why we didn't enable that as a replacement.
-
-
The latest sysfsutils code appears to have been released and last updated in 2006 so whatever it is or does is probably superseded by other tools by now. It's also the first time I heard of anyone requesting it (in the decade+ time I've been hanging around the project) so the number of users who might think it's handy is probably you and .. (don't hold breath).
Step back a level. What were you trying to do?
-
The same has been reported on aother Allwinner board so there's likely an issue in the u-boot (or related code) somewhere that's used to perform initial boot. We've pinged the main Allwinner maintainer, but he's on an extended vacation so there might be a delay in someone seriously looking at the issue .. I'm not sure if other staff have hardware to test with.
-
-
I’d start with updating a current LE (and thus Kodi) release. I doubt any developer is testing addon code on Kodi Matrix these days.
-
Even if the TV is 4K the Kodi desktop should be run at 1080p: https://wiki.libreelec.tv/configuration/4k-hdr
-
If you append video=HDMI-A-1:1920x1080M@60 to boot params in cmdline.txt (to force the initial kernel DRM state to 1080@60) does that solve the issue? - I'm wondering if it's trying to output at 4K (for reasons unknown) and the TV isn't liking that.
I'd also be interested to know what shows on screen if you remove the SD card and let the RPi boot to the test screen. Does it show that an HDMI device (and EDID) are detected?
-
Argon cases are "the gift that keeps on giving" for support issues
-
I'm wondering if this might be relevant: https://patchwork.kernel.org/project/dri-de…s.qualcomm.com/