Is this working with the internal ARC GPU or only external ones since you mentioned PCIed ?
This is on the integrated iGPU
# lspci
00:00.0 Host bridge: Intel Corporation Device 4621 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
…
Now you have a mostly working system, can you share the debug logs.
Note: I don’t have any whitelists/etc on my Alder Lake for 4K HDR playback (LG tv)
usual suggestions to test - nothing between your TV and PC - no AVR…. Compliant HDMI cable…
Jumping ahead - I have begun testing the “xe” driver versus the “i915” driver which requires an edit to the /flash/syslinux.cfg APPEND line - in my case i915.force_probe=!4626 xe.force_probe=4626 - not saying that this is a fix, but is where Intel are investing time in for the modern iGPU driver. You will need your VGA cards PCIid if you are testing this.
LE12 will only be release with the 6.6 kernel.
There is an Omega image in the LE13 nightlies (before we switched to K22 Piers) is has kernel 6.9.5 - link below. Otherwise it would require a custom image.
Everything after that is K22.
https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20240714-c780187.img.gz
Please provide a full debug log.
How to post a log (wiki)
1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link
drjackel - im not sure in the /vtoy/vtoy error that is coming up. are you running some bootloader or ventoy or ??
I have explained it a few times now. But I will again for clarity.
Jobs are scheduled (if there are changes in the last 24 hours and an image will be built, it does not check it an image of that hash exists already.)
Jobs are also run manually, in this case the RPi ones were run to address a RPi 2GB built “quickly.”
There is nothing to be read into the images with different dates and the same hash. There maybe many of the same hash, you are welcome to use any off them, though the contents will have different compile dates, they will be from the same source.
Hope this fully answers the questions.
lets try direct as a way to validate that issue.
but does seem to point to be a "compatibility issue" of the Nvidia drivers in 11.0.6 versus 12.0
would be good to see if the LE13 nightly has the same issues (it is running a newer version of nvidia drivers)
https://test.libreelec.tv/13.0/Generic/Generic-legacy/LibreELEC-Generic-legacy.x86_64-13.0-nightly-20240826-7643d36.img.gz
dipswitch the pastekodi log is from "Starting Kodi (20.3 (20.3.0) Git:20.3-Nexus). Platform: Linux x86 64-bit" and the smb log is from "Starting Kodi (21.1 (21.1.0) Git:21.1-Omega). Platform: Linux x86 64-bit"
I can see Nvidia in the nexus log
2024-08-27 21:56:32.916 T:1101 info <general>: CRenderSystemGL::InitRenderSystem - Version: 4.6.0 NVIDIA 470.161.03, Major: 4, Minor: 6
2024-08-27 21:56:32.916 T:1101 info <general>: GL_VENDOR = NVIDIA Corporation
2024-08-27 21:56:32.916 T:1101 info <general>: GL_RENDERER = NVIDIA GeForce GT 1030/PCIe/SSE2
2024-08-27 21:56:32.916 T:1101 info <general>: GL_VERSION = 4.6.0 NVIDIA 470.161.03
2024-08-27 21:56:32.916 T:1101 info <general>: GL_SHADING_LANGUAGE_VERSION = 4.60 NVIDIA
2024-08-27 21:56:32.916 T:1101 info <general>: GL_GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX = 2097152
2024-08-27 21:56:32.916 T:1101 info <general>: GL_GPU_MEMORY_INFO_DEDICATED_VIDMEM_NVX = 2097152the pastekodi is a mix of nexus and omega:
the "journalctl -a -b -0" is Omega and the "/storage/.kodi/temp/kodi.log" is Nexus
Suggest using the USB Key boot (using the run option) before doing too much - this will isolate what is happening.
Hi.
Where get latest verion of LinreElec RR ?
RR is a fork of LibreELEC - this is the repository https://github.com/SupervisedThinking/LibreELEC-RR
I have tested LE with an AMD Ryzen 7 7840HS w/ Radeon 780M Graphics with success.
I would probably not recommend a PC with a external video card for a htpc, nor change the video card if your current device is working for you.
Thanks! Also for LE12 RPI 5 version?
these have all been built and made available.
Your probably reading too much into it. The build system runs many workflows and then many jobs within those workflows. We have been doing extra LE12 builds recently which will push out or cancel other builds. When a workflow runs - it runs 2 jobs at a time (in random order for the target architectures) and will pick the hash at the time of the job kick off - not the workflow kickoff.
Whilst the job is scheduled nightly - it doesn’t mean there will always be a nightly.
You can always check the scheduler for LE13 builds at https://github.com/LibreELEC/acti…/build-LE13.yml
Or in total at https://github.com/LibreELEC/actions/actions
may help the crystal ball be less cloudy.
If the issue is the same as the WebDAV issue, then the le12 nightly has the fix. https://github.com/LibreELEC/LibreELEC.tv/pull/9178
retrofan it’s in the backlog of addon updates that are planned - these are usually chunked up (makes it easier do these custom package updates.) won’t be too far away, but we have been working on some other areas last couple of weeks.
And? Read 2nd paragraph. And if interested take a look at - https://github.com/LibreELEC/actions/actions
You can check the inner workings of the CI/CD environment here. https://github.com/LibreELEC/actions/actions builds of LE12 and LE13 take 18 hours each, and addons take 10-12 hours each. Builds only get kicked off if there have been changes in the last 24 hours. Workflows can only be in the queue for 24 hours. Priority is given to binary addons when required.
So when only LE12 or LE13 are getting changes, you will see images and addons updated every 28-30 hours, but when changes are occurring on both LE12 and LE13 - you will see a 60 hour cycle.
Workflows are cancelled automatically when passing 24 hours. Workflows (addons / images) are also cancelled when they won’t actually make change - eg addon update doesn’t need images rebuilt - because they were the same.
Hope that answers your questions.
Display MoreWell. I booted from ISO , menu-setup not showed my target-iSCSI. I switched to concole, tried command :
iscsiadm -m dicscovery -t sendtargets -p 192.168.1.97:3260
Answer -
iscsiadm: Could not perform SendTargets discovery: iSCSI driver not found. Please make sure it is loade and retry
What I may do ?... May be need patch kernel or apply change in file kernel_options ?
This bit I can’t help with, as I haven’t used iscsi.
