12.0.0.5 is available now
Posts by heitbaum
-
-
-
Revert queue for le12. https://github.com/LibreELEC/LibreELEC.tv/pull/9776
Le13 will need further work - due to depends for a revert (libfmt/c23) - so will look in to the fix / upstream issue
-
I’m pretty sure if you do: ldd /storage/.kodi/addons/service.softcam.oscam/bin/oscam there will be a missing library. I have queued up the bugfix.
-
Please share systemctl status service.softcam.oscam.service
-
Please update to latest nightly. Likely glibc 2.41 dependency
-
Something before 23rd December - this is when ffmpeg was merged - https://github.com/LibreELEC/Libr…0e3ed829a1d+210 “Merge pull request #9569 from HiassofT/le13-ffmpeg-7”
-
Waiting on the upstream changes to be incorporated and a new version being shipped. https://github.com/xbmc/inputstream.ffmpegdirect/pull/304
-
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.9the 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
-
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 -
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.tvrelease notes: https://github.com/jellyfin/jellyfin/releases/tag/v10.10.0 https://github.com/jellyfin/jellyfin/releases/tag/v10.10.1github.comjellyfin: update to 10.10.1 and addon (5) by heitbaum · Pull Request #9502 · LibreELEC/LibreELEC.tvrelease 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
RPi5.aarch64 13.0 / build_image
This request was automatically failed because there were no enabled runners online to process the request for more than 1 days.
This request was automatically failed because there were no enabled runners online to process the request for more than 1 days.
-
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.
