just checked - unfortunately same error …
Just confirming - this is using both the LE12 nightly 20240130-af98f8f with the custom compiled pvr.vuplus-21.1.1.2.zip ?
Posts by heitbaum
-
-
-
I’m building a zip of pvr.vuplus against Kodi cabba8d. Which is in https://test.libreelec.tv/12.0/RPi/RPi5/…-af98f8f.img.gz for you to test. I don’t see anything specific either, but there has been some internal Kodi dependancy change in cabba8d.
-
I believe I can see that tethered mode is set on your Librelec. Can you please check and disable.
-
It’s kicked off daily at 14:15 UTC.
Build for LE12 (18 images) takes roughly 18 hours.
Just checked 5 image builds left to go. -
For LE12. We initially were continuing to run arm32 on the 64bit devices. All 64bit devices are now running aarch64 (Rockchip was one of the last to be changed over.)
When changing over from arm to aarch64 you will need to update the binary addons.
I’m not sure on the LE check itself - by Manual intervention using the .update folder is the way forward.
** In LE12 there are no more arm builds for the 64bit systems, only aarch64.
-
They are there it’s just the sort that is wrong. And arm versus aarch64.
Search for:LibreELEC-RK3328.aarch64-12.0-nightly-20240116-b7b2da0-rock64.img.gz (sha256)
-
Thanks for the info. I am glad to hear that Nucs are still extensively used for testing. I am however sorry to learn, that especially the 11gen have issues. The reason I got myself a nuc11 after years of happy using a nuc5 was that the nuc11 are the last ones with CIR. Also the nuc12 seemed even more overkill. I guess I'll now have to wait for the ASUS p42 with a n100 to start working, although I'd rather prefer my Nuc11. It's the smallest i3 (the pentiums don't have CIR). Any chance the nuc11 issues (what are they one you know about?) get resolved. I have issues with Audio coming and going and passthrouh not working as mentioned above near the starting posts of this thread.
The other issue has to do with the tv.hts client not playing uhd streams with VAAPI, which, I guess, is not really related to the chip.I haven’t tested nuc11 for ages but the pass through “issue” I was able to reproduce on the NUC11PAHi7 regularly. The coming and going audio I have not experienced. The issue I experienced was “audio goes” and a reboot was required.
-
Some clarification - Intel NUC is used heavily and extensively in testing of all LE releases - specifically a NUC12WSKi7, and previously NUC6,10,11. There are known “issues” with audio on NUC11 that I have personally experienced, but are not occurring on a NUC12WSKi7. So not sure what issues are being referenced. There are LSPCON issues in some NUC devices that have caused issue.
Note: when using “new” (not yet upstreamed hardware) e.g. the AX100 wireless, some of the N100 chips … there will be 12-18 months of pain for the purchaser (note - I run bleeding edge software (and release candidate / patches) - to allow testing and running on these newer generations of hardware.) so LE is pretty much up to date as much as possible for support of newer hardware. But if the hardware being purchased is not fully supported by Kernel 6.6.y for Intel equipment (I can only vouch for the NUC mentioned) then you will have issues as this is the release that we are going with for LE12.Next thing is unfortunately Intel has left the NUC business, and as an avid NUC users, have not decided on my next Intel direction. But after LE12 is released - I will probably be focussed on using the AMD Beelink SER7 - but this will bring its own challenges.
-
You will want to start here. So not a generic or generic-legacy image.
To be forewarned - scripts/build Kodi is currently failing in this make image.
PROJECT=Generic ARCH=x86_64 DEVICE=wayland make image -
ghtester addon is updated now
-
The plugins are not built (except the pulse ones - but then only from the snapcast addon)
GitHub - alsa-project/alsa-plugins: The Advanced Linux Sound Architecture (ALSA) - pluginsThe Advanced Linux Sound Architecture (ALSA) - plugins - GitHub - alsa-project/alsa-plugins: The Advanced Linux Sound Architecture (ALSA) - pluginsgithub.compackages/addons/service/snapclient/package.mk:PKG_DEPENDS_TARGET="toolchain alsa-plugins snapcast"
LibreELEC.tv/packages/addons/addon-depends/snapcast-depends/alsa-plugins/package.mk at master · LibreELEC/LibreELEC.tvJust enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.github.com -
-
No LE11 docker updates are planned. There have been changes in the addon that were not suitable for stable. For a self build, you will probably be ok with the bump and dependencies - but untested.
-
LE12 already has this up to date
# docker version
Client:
Version: 24.0.7
API version: 1.43
Go version: go1.21.5
Git commit: afdd53b4e341be38d2056a42113b938559bb1d94
Built: Fri Dec 15 06:32:26 UTC 2023
OS/Arch: linux/amd64
Context: defaultServer:
Engine:
Version: library-import
API version: 1.43 (minimum version 1.12)
Go version: go1.21.5
Git commit: library-import
Built: library-import
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: 1.7.11
GitCommit: 4e1fe7492b9df85914c389d1f15a3ceedbb280ac
runc:
Version: 1.1.10
GitCommit: 18a0cb0f32bcac2ecc9a10f327d282759c144dab
docker-init:
Version: 0.19.0
GitCommit: -
First I've tested "y", but also no install.
If you update your docker container to the latest, you should be fine.
https://github.com/LibreELEC/Libr…/Dockerfile#L24 -
Also I don’t know if the firmware / comments on “however for a stable link at 1Gbps firmware revision ….” are relevant.
-
I can see the eth0 and eth1 in your dmesg too. And nothing untoward.
This post goes through the particular card. It would be worth checking each step.eth1 is a bit strange - in that it shows an MTU of 9000.
Both eth0 and eth1 are not showing any traffic and I can’t see the cable “connect” / “disconnect”
I’m not sure where this script is from? /storage/.config/system.d/mtuchange.service from the 02_System log.
