Posts by heitbaum

In LE12 we moved the libraries to lib.private to keep them from colliding and cluttering the LD_LIBRARY_PATH.

nuc12:~ # find .kodi/addons/ | grep libfuse.so
.kodi/addons/virtual.system-tools/lib.private/libfuse.so
.kodi/addons/virtual.system-tools/lib.private/libfuse.so.2
.kodi/addons/virtual.system-tools/lib.private/libfuse.so.2.9.9
.kodi/addons/virtual.network-tools/lib.private/libfuse.so
.kodi/addons/virtual.network-tools/lib.private/libfuse.so.2
.kodi/addons/virtual.network-tools/lib.private/libfuse.so.2.9.9

the rpath has been updated on the binaries

nuc12:~ # ldd .kodi/addons/virtual.system-tools/bin/mtpfs
linux-vdso.so.1 (0x00007f34ba525000)
libfuse.so.2 => /storage/.kodi/addons/virtual.system-tools/bin/../lib.private/libfuse.so.2 (0x00007f34ba4e1000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f34ba2ec000)
libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x00007f34ba2d7000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f34ba119000)
libudev.so.1 => /usr/lib/libudev.so.1 (0x00007f34ba0ca000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f34ba527000)

The code that does this is: https://github.com/LibreELEC/Libr…package.mk#L194

Quote from mglae

heitbaum 20230309 is older than 12.0.1 of 2024-10-17

Oops - didn’t read that.

dembala please try current LE12 nightlies. As 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

These are at https://test.libreelec.tv/12.0/ (scroll to the end an use the latest 202412xx image.

Nightly 12 has the fix (after 12.0.1) RE: SFTP broken in LE12

I have looked at buildx a few times, there is a PR in my dev tree for it. It is a bit messy to build, and on my long term backlog.

27.4.0 is in the LE13 nightlies. 27.4.1 is in the backlog.

LE12 has 27.3.1 in it

- https://github.com/LibreELEC/Libr…-depends/docker

- https://github.com/LibreELEC/Libr…47241ce56b63528

rkershenbaum best shared the logs here now that kernel 6.12 is regressed from 6.6.x https://github.com/LibreELEC/Libr…ment-2455713147 to 6.12 https://github.com/LibreELEC/Libr…ment-2531602564

Addons PR updated to the latest - previous Jellyfin downloads have been removed from the Jellyfin download server.

jellyfin: update to 10.10.1 and addon (2) by heitbaum · Pull Request #9501 · LibreELEC/LibreELEC.tv

release notes: https://github.com/jellyfin/jellyfin/releases/tag/v10.10.0 https://github.com/jellyfin/jellyfin/releases/tag/v10.10.1

github.com

jellyfin: update to 10.10.1 and addon (5) by heitbaum · Pull Request #9502 · LibreELEC/LibreELEC.tv

release notes: https://github.com/jellyfin/jellyfin/releases/tag/v10.10.0 https://github.com/jellyfin/jellyfin/releases/tag/v10.10.1 Backport of jellyfin:…

github.com

Annotations

2 errors

Not a bug as such, but simply they are not yet supported. Looking at the open tickets and the above seems to be getting to the bottom of the wireless issues reported, this is a good another “now known” item.

The list probably looks like the below now: (noting that these are shortcomings in drivers, kernels, supplicants, ….) The “But it should work” philosophy whilst idealistic is not true even in commercial / non iwd / non LE landscapes. Wireless will probably always have its challenges given standards and compatibility across the many elements that make it up - but every known reproducible issue should improves our support and hopefully the Linux wireless ecosystem system.

Known issues

• wireless networks with FT enabled may not work
• wireless networks with WPA3 may not work
• wireless networks where the signal strength is low may not authenticate
• The wl bcm_sta driver (at this stage) will be dropped from LE13 - (lack of patches to make it compatible with linux 6.12)
  
  For these 4 known issues - there does seem to be movement upstream in “fixing“ / “adding support for”

Yes. Maybe. No.
Answer will depend.

In my case - I run nightly+ on my daily system (Generic ADL) , but am developing everyday as you would see. The operating system is starting to take shape for the LE13 release, in that the big changes - compilers, libraries, kernels are pretty much done. So no major changes at the operating system level that would impact are expected. We will be updating to the next Mesa soon.

As a developer, I run RC software packages, so that we try and address issues with “new packages” before they are released - thus I try to be on the front foot so that the commits are soak tested first. The team in both Kodi and LE do the same.

There are kodi changes happening (api) that will mandate changes/updates to addons, and this will continue through to the release of Kodi Piers. These may cause you to have to update - if you use these.

You will need to decide what’s best for you, but if you stay on a version “eg the early sept one” and don’t have fixed the issue you are trying to address, then when the LE13 does come out, the issue may still not be fixed in the release version. In the case of using “new hardware”, I would stay using recent nightlies, to make sure that they work with your system. Older hardware is usually more stable in the linux kernels/graphics software.

based on Chewitts answers - I would fix your system so that it can play all, as if there is another issue that comes, it might not get fixed. If there is a further problem that is not whitelist. So GUI in 1920x1080 and whitelist max 3840x2160.

Here is the log between those 2 versions

Comparing ce869d0...56c531c · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

This is the only patch (that may be of issue) - https://github.com/LibreELEC/Libr…59e13377e8b3dc5

I can see a few things.

You are using the xe driver - good (as the kernel log indicates that 4908 is not supported properly by the i915 driver.)

The Kodi gui is 4096x2160 - suggest setting this back to HD

I believe from the logs that the GUI is working - please confirm

I believe from the logs the “bootsplash” is working - please confirm

From the playback logs, you can see that koi probably picks the wrong resolution for playback of the HD stream. Use the whitelist, get it to use a HD resolution.

The stream you are playing is broken - see ffmpeg logs.

Please test a known working file. E.g. 2D BBB - http://bbb3d.renderfarming.net/download.html

I am compiling a nightly image for you to test (current master + the 6.12-rc4 linux) download from https://heitbaum.libreelec.tv - will be there shortly.

vendor_id:    0x8086
device_id:    0x4908
make: 'SKYDATA S.P.A.' model:

2024-10-23 20:19:43.310 T:1685     info <general>: GL_VENDOR = Intel
2024-10-23 20:19:43.310 T:1685     info <general>: GL_RENDERER = Mesa Intel(R) Graphics (DG1)
2024-10-23 20:19:43.310 T:1685     info <general>: GL_VERSION = OpenGL ES 3.2 Mesa 24.2.3

2024-10-23 20:19:43.518 T:1685     info <general>: GUI format 4096x2160, Display 4096x2160 @ 60.000000 Hz

2024-10-23 20:21:41.518 T:2450     info <general>: Opening stream: 0 source: 256
2024-10-23 20:21:41.518 T:2450     info <general>: [WHITELIST] Searching the whitelist for: width: 1920, height: 1080, fps: 23.976, 3D: false
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Using the default whitelist because the user whitelist is empty
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Searching for an exact resolution with an exact refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] No match for an exact resolution with an exact refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Searching for an exact resolution with double the refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] No match for an exact resolution with double the refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Searching for an exact resolution with a 3:2 pulldown refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] No match for a resolution with a 3:2 pulldown refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Searching for a desktop resolution with an exact refresh rate
2024-10-23 20:21:41.518 T:2450    debug <general>: [WHITELIST] Matched a desktop resolution with an exact refresh rate 4096x2160 @ 23.976025 Hz (25)
2024-10-23 20:21:41.518 T:2450     info <general>: Display resolution ADJUST : 4096x2160 @ 23.976025 Hz (25) (weight: 0.000)
2024-10-23 20:21:41.547 T:1685    debug <general>: ------ Window Init (DialogBusy.xml) ------
2024-10-23 20:21:41.548 T:1685    debug <general>: OnLostDevice - notify display change event
2024-10-23 20:21:41.752 T:1685     info <general>: VideoPlayer: OnLostDisplay received
2024-10-23 20:21:41.752 T:1685  warning <general>: CDVDMessageQueue(audio)::Put MSGQ_NOT_INITIALIZED
2024-10-23 20:21:41.752 T:1685  warning <general>: CDVDMessageQueue(video)::Put MSGQ_NOT_INITIALIZED
2024-10-23 20:21:41.752 T:1685    debug <general>: Flush - flushing renderer
2024-10-23 20:21:41.752 T:1685    debug <general>: CDRMUtils::SetMode - found crtc mode: 4096x2160 @ 24 Hz
2024-10-23 20:21:41.752 T:1685     info <general>: GLES: Maximum texture width: 16384
2024-10-23 20:21:41.753 T:2450     info <general>: Creating video codec with codec id: 173
2024-10-23 20:21:41.753 T:2450     info <general>: CDVDVideoCodecFFmpeg::Open() Using codec: HEVC (High Efficiency Video Coding)
2024-10-23 20:21:41.753 T:2450    debug <general>: CDVDVideoCodecFFmpeg - Updated codec: ff-hevc
2024-10-23 20:21:41.753 T:2450    debug <general>: CVideoPlayerVideo::OpenStream - open stream with codec id: 173

2024-10-23 20:21:47.792 T:2489  warning <general>: VAAPI::SupportsFilter image format not NV12
2024-10-23 20:21:47.800 T:2452    error <general>: ffmpeg[0xa79b200]: [hevc] Could not find ref with POC 0
2024-10-23 20:21:47.800 T:2452    error <general>: ffmpeg[0xa79b200]: [hevc] Could not find ref with POC 5
2024-10-23 20:21:47.800 T:2452    error <general>: ffmpeg[0xa79b200]: [hevc] Could not find ref with POC 9

Guessing kernel 6.11 upset it.

Comparing b5d3f6e...master · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

Comparing b5d3f6e...8602b53 · LibreELEC/LibreELEC.tv

Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.

github.com

So the 29 September 8602b53 image fails?

Can you share the pastekodi?

PR - Pull Request.

Based on mglae info - the 8086:4b32 device has both the network devices behind it.

The ec1000s is a USB to Ethernet adapter using the r8152 chip. I can see that in your dmesg.

What do the following commands show

lsusb

ifconfig

lshw -c network # part of system-tools addon

as a point of note - iwd and connman in LE12 nightlies are now the same as that in the LE13 builds. So, any testing with LE12 should be undertaken with the nightlies - and hopefully there is improvement in the support. There have been some issues that have been addressed in iwd.

So any logs with a cause / resolution could be shared with the iwd/connman teams.

The card is a nvidia ion. There are reported issues with this in some releases.

Search - LibreELEC Forum

So it’s this one, (you can confirm by remove/adding it in between running lspci)

Bus 001 Device 003: ID 2013:0462 PCTV Systems PCTV 461

==
Can you please run lsusb -d 2013:0462 -v

Also journalctl -f when you insert the USB, as the dmesg in the debug log does not show the device at all.

==
Answer seems to be here (Message 8 - no go) - https://tvheadend.org/d/8633-dvb-s2-…configuration/8 not sure if there have been changes since.

There are lots of references here -

Missing support for Pinnacle 461e Rev 3 BBH9 · Issue #170 · b-rad-NDi/Ubuntu-media-tree-kernel-builder

This appears to use a newer Montage M88DS3103C demodulator USB details Bus 003 Device 007: ID 2013:0462 PCTV Systems PCTV 461 Inserting device under Fedora 40…

github.com

WinTV-Nova-S2 USB revision BAH9 (PCTV_461E) support, work around and fix · Issue #162 · b-rad-NDi/Ubuntu-media-tree-kernel-builder

Just repeating the issue raised here: b-rad-NDi/media_tree#12 I created a /etc/modprobe.d/dvb.conf with the contents: options em28xx card=92 Ran a depmod -a…

github.com

And 12, 13, ….

There are some modprobes in 12 that might be worth testing to confirm your card version.