There are 3-4 different chipsets used in most USB-Ethernet adapters and these should all be supported. If a device is not working (and you cannot get the NUC online) you need to dump the log to a USB drive "dmesg > /var/media/USBDRIVE/dmesg.log" (change for whatever the path to the device is) and then upload/pastebin the log so we can hopefully see what the issue is. You won't get a "buy this one!" purchase recommendation because most adapters are cheap/no-name branded and manufacturers are in the habit of changing the chips inside the adapter between different batches/versions of the device.
Posts by chewitt
-
-
If defaults are configurable and should be corrected, please find a way to change the defaults.
-
The kernel is something that moves forwards continuously and relentlessly so the adage "If you stand still, you're actually moving backwards" applies in a big way and because (for good reasons) people became inactive for a while a whole heap of WIP changes got parked for a while. I don't think there's a single series, it's more a case of "a little bit of everything" as the kernel evolved.
-
Honestly, I'm not sure this brings value for you - maybe it does
Several of the project staff have experience with Yocto/OE for other projects and work requirements and it has inspired changes to our own in the past. It does benefit from having far greater build capabilities, but it's also quite a bit more complex and is thus less accessible to the type of hobbyist developers we attract (for our hobbyist distro) and that's long recognised as something important for the project and the ecosystem of forks that surround us. In that sense it's an interesting exercise to see, and kudos for getting things as far as bootable images, but I think we're unlikely to change the buildsystem we use.
Things I'd like to see done (which we mostly know how to do, but time..) is moving to a reusable toolchain as this would massively reduce the total time required for building nightly images with CI and would probably allow us to test-build PR's. The uboot_helper script could also be expanded to more of a build-matrix function; e.g. https://github.com/LibreELEC/LibreELEC.tv/pull/6427 which has bit-rotted a little as people's lives changed and became less active. We are laggards at adopting things largely due to being a bunch of hobbyists and the desire to not fcuk up something that basically works
-
It's not an issue for YUV media to be converted and output in an RGB colourspace as long as it's done correctly (there are specs and broadcast standards for doing it). It's far more important for Kodi to open a proper 10-bit plane and use the correct buffer types for the media to avoid ffmpeg silently downsampling YUV 4:2:0 10-bit to 8-bit (the default on Intel hardware since forever) and similar bad things. Have a read through the list of PR's here https://github.com/xbmc/xbmc/issu…hor%3Areardonia (merged) and https://github.com/xbmc/xbmc/issu…hor%3Areardonia (pending, but patched in that image) for a more detailed understanding of the issues being resolved. TL/DR "It's RGB" is rather missing the point
-
I'd be interested to know how you see this image behave? It has a whole heap o' changes including proper 10-bit and 4:2:2/4:4:4 support. https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz
-
Your post is rather lacking in details and it's not clear what the purpose of that lib is ..
-
I'm aware the HDMI chain on RK3288/RK3328/RK3399/RK3566/RK3568 (all chips that use dw-hdmi, not dw-hdmi-qp) is probably a little borked at the moment. The older patches (2018-2022) have now bit-rotted to the point where things are breaking on newer kernels and need reworking. Kwiboo is actively working on that and he's started to send replacement patch series to the kernel mailing lists, but the total number of patches is huge (150+) and right now only ~3/8 series are submitted. I plan to rework our kernel patchset this week to drop older patches and start including them, but this will be a "two steps forwards, three steps backwards" move as Jonas is (re)building the base functionality first. Older patches that add e.g. 4K/HDR support are unlikely to be useable so I expect capabilities to regress until more of the rework lands. Older LE releases with older kernels/patches before breakage are probably more functional on the above hardware at this point of time.
-
chewitt would this mean that a LE 12.0 build might not have the same issues?
I don't have the hardware so have no personal baseline understanding of what the state of older images is. We don't charge for downloads or testing though, so you can try them.
-
At the current time "you get output" .. what bit-depth, colourspace and colour-range I've no idea. It's probably not brilliant as we're forced to use the elFarto VAAPI shim until Kodi gains NVDEC support. There are also quite a few things to unwind/redo in Kodi's EGL rendering path to resolve. The x86 world is oriented towards RGB rather than YUV but this isn't an issue as long as things are being done right, i.e. fixing some of the limited/full range issues in the display chain; which is actively being worked on. So no advantages over Intel/AMD that I can see (both suffer from some of the same RGB issues) and I'd still advise anyone considering new purchases to avoid nVidia cards until more of the plumbing has been straightened out.
NB: Support for nVidia now means only GPU's that can use the 580.xx driver series; and we've intentionally held off bumping to the latest driver because that orphans eveything before RTX cards. Current stats show nVidia tiny user numbers on the 580.xx driver, though to be fair we have been telling users to avoid nVidia cards for the last decade so there's an element of "built it and they will come" in-play. I'd expect numbers to increase once there is clear direction on support.
-
Note that we have previously rejected addition of upower items as they really aren't needed with LE and we seek to avoid "the death of a thousand cuts" from adding bloat. Adding support into the buildsystem to benefit Lakka use-cases is fine; as long as inclusion is configurable from options.
-
I pushed new test images to my share with Linux 7.0.8 kernel that include the HDMI rework from Kwiboo that's currently on the mailng list. Kodi has bumped DB versions so initial restart after updating might take as the DB's need to be migrated.
The main notable change is BT working on the WP2 box. It turns out we were using the wrong Broadcom firmware; the box runs the chip at 26MHz, the firmware was for 37.4MHz, so once the correct one was substituted it started working.
-
is it possible to easily convert to a LibreElec Box with Remote or rather difficult?
You can have a look at the image that ilmich releases for older hardware, but that's the sole option (and not guaranteed). There is not much support upstream for the RK3318 chipset (and thus no point in making official LE images).
-
Screenshots haven't worked (except on X11 images) for a long time. It's a consequence of the zero-copy video pipeline.
-
Maybe LE can offer NVidia as a new separate gz package?
Nope. If we claim support for nVidia GPUs it needs to work OOB.
The other option is replacing Generic-Legacy (X11) with an nVidia/GBM image for LE13 to still effect the underlying architectural change but avoid the size-bump for LE13, but we'd want to consolidate for LE14 regardless so it's only delaying the inevitable.
-
It doesn't matter how old the HiFi bit are; if they sound good, they sound good. IMHO a slim case would be better, but as you said, there aren't so many choices these days, and none are cheap. If it works, don't fix it
-
The default boot partition was enlarged from 512MB > 1GB last year to accomodate nVidia driver increases over time, and Generic now (since yesterday) supports current nVidia GPU cards hence the sudden size increase.
The fastest workaround is to use the backup function in the settings add-on (captures /storage/.cache|.config|.kodi) and move that off box, reinstall to create a clean instance with larger boot partition, then restore the backup. Beware anything outside of those ^ folders that you also want to preserve. Resizing partitions can also be done using e.g. Gparted on an Ubuntu LiveUSB, but it will be significantly slower (10x slower if not more).
-
The RockPro64 HDMI bridge driver (dw_hdmi_rockchip) hasn't been updated yet. The HDMI bridge initializes incorrectly, causing all HDMI connector-level DRM property writes to fail with EACCES (-13). This is also why Kodi has no display on LE 13 RockPro64, Kodi uses KMS atomic commits too and hits the same broken bridge.
There are patches on the mailing list from Kwiboo to address this:
I will rework the rockchip patches to include them over the next week, although this will likely cause a regression since the colour related changes that are also needed for parity with older RK images (on older kernels, before the old patches bit-rotted) aren't available just yet. Soon hopefully..
