This image contains ffmpeg 6.1.1: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar
No idea if that fixes or adds problems. Have a play..
Definitely has the fix. Thanks!
Taking it for a short spin, haven't noticed any new issues.
This image contains ffmpeg 6.1.1: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar
No idea if that fixes or adds problems. Have a play..
Definitely has the fix. Thanks!
Taking it for a short spin, haven't noticed any new issues.
My Odroid C2 is still having issues playing ogg vorbis. Looking at github it looks like Amlogic is still back on ffmpeg 6.0 instead of 6.0.1. Any chance of getting that minor bump to pick up the fixes for voribs and flac?
Tested v12 nightly and v13 nightly.
I have a bit of a few things going wrong that seem to be all related. Odroid C2, LE 12 nightlies.
Issues started popping up a few weeks back.
First issue, the system would often be found with a non-responsive GUI after it had been left idle, so screen saver active and eventually display shutdown. The display would turn back on, so CEC was still working, but the GUI would be frozen. Sometimes you could here the remote "clicks", but still the GUI was frozen. This sounds like https://github.com/LibreELEC/LibreELEC.tv/issues/8488 however I haven't any of those EGL errors.
Second issue that started at the time was glitchy video playback IF using hardware acceleration. Basically, every so often, randomly, the frames momentarily freeze and/or are rendered in the wrong order. Truly random, the glitches don't occur in the same places when re-watching the video. Switching it to purely software decoding, either PRIME or EGL, and the issue appears to go away. Considering it had previously been working fine until sometime in December, and the randomness of it, could this be a timing issue that the EGL fence causes?
The following is a log where a video was started and had some glitches within the first few minutes then playback was stopped,
I'm still trying to get a log from the frozen GUI
Known issue and fixed upstream already. Will get pulled in next time someone bumps Kodi.
chewitt is the team aware that the LE12 nightlies for arm are not showing up on the download page?
I just noticed on my x86-64 based system that with the nightlies I have some libraries with invalid symbolic links. I was wanting to try fixing it however I'm having a hard time identifying where those links get generated when building. Specifically the libraries I'm looking at libGL and libGLX, which you can see below are pointed at the wrong directories:
lrwxrwxrwx 1 root root 10 Sep 23 14:25 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 17 Sep 23 14:25 /usr/lib/libGL.so.1 -> /var/lib/libGL.so
-rwxr-xr-x 1 root root 538960 Sep 23 14:25 /usr/lib/libGL.so.1.7.0
lrwxrwxrwx 1 root root 11 Sep 23 17:01 /usr/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root 15 Sep 23 17:01 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 461768 Sep 23 17:01 /usr/lib/libGLU.so.1.3.1
lrwxrwxrwx 1 root root 11 Sep 23 14:25 /usr/lib/libGLX.so -> libGLX.so.0
lrwxrwxrwx 1 root root 18 Sep 23 14:25 /usr/lib/libGLX.so.0 -> /var/lib/libGLX.so
-rwxr-xr-x 1 root root 133712 Sep 23 14:25 /usr/lib/libGLX.so.0.0.0
lrwxrwxrwx 1 root root 15 Sep 23 14:25 /usr/lib/libGLX_glvnd.so.0 -> libGLX.so.0.0.0
lrwxrwxrwx 1 root root 29 Sep 23 14:25 /usr/lib/libGLX_indirect.so.0 -> /var/lib/libGLX_indirect.so.0
lrwxrwxrwx 1 root root 16 Sep 23 17:01 /usr/lib/libGLX_mesa.so -> libGLX_mesa.so.0
lrwxrwxrwx 1 root root 20 Sep 23 17:01 /usr/lib/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rwxr-xr-x 1 root root 459984 Sep 23 17:01 /usr/lib/libGLX_mesa.so.0.0.0
-rwxr-xr-x 1 root root 1289616 Sep 23 17:04 /usr/lib/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root 14 Sep 23 14:25 /usr/lib/libGL_glvnd.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 root root 1267800 Sep 23 17:04 /usr/lib/libGL_nvidia-legacy.so.1
lrwxrwxrwx 1 root root 18 Sep 23 14:25 /usr/lib/libGLdispatch.so -> libGLdispatch.so.0
lrwxrwxrwx 1 root root 22 Sep 23 14:25 /usr/lib/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
-rwxr-xr-x 1 root root 711128 Sep 23 14:25 /usr/lib/libGLdispatch.so.0.0.0
Display More
If someone could please point me in the correct direction. Thank you!
Turns out whether those libraries exist in /var/lib seems to be controlled at boot time. In testing a boot switch for my hardware, it disabled those files existing.
I have found an issue with GBM, confirmed with both Generic and Amlogic, when configured as limited colour range. The issue being that images lines for dvb subtitles have the range conversion applied twice. In other words, the lines where dvb_subtitles are rendered, not just the text but the whole width of the screen appears lighter then the rest of the screen.
This does not occur with Generic-Legacy (X11) nor Kodi (X11) on Ubuntu 22.04 (x64).
I can provide a kodi debug log, however I'm not sure it would help.
The current nightlies are using CONFIG_DRM_MESON=y, and has been for 4 years
You can also confirm from the currently running kernel by cat /proc/config.gz | gunzip | grep -i DRM_MESON
There has been a continual up and down over the last couple years with regard to the reboot issue.
If you try a google, there is a back and forth breakage between the Kernel and u-boot. General summary seems to be related to the power for attached devices, e.g. SD-Card, USB, EMMC, so what you have attached also seems to impact whether you are impacted or not. Even just changing the speed of SD-Card has an impact.
For any of the Libreelec team, the following might be of some help if you hadn't already seen:
Armbian - meson64: edge: rework to kernel 5.19 which with regard to the reboot issue just references
This discussion of CONFIG_DRM_MESON=m vs. CONFIG_DRM_MESON=y in terms of a broadly acceptable solution.
Armbian's later update to Kernel 6.0.13 continued to follow suit on CONFIG_DRM_MESON=y
Using the latest Generic-Legacy nightlies, there are missing library dependencies for the music visualization plugins. Seems to be a case of the plugins being compiled for Generic (GBM) instead of Generic-Legacy (X11). Below is for shadertoy, but the others are similar.
I had cleaned out any archived copies in the packages folder, so I don't think it got a previously cached copies of the plugins.
ldd: $warning: you do not have execution permission for `./visualization.shadertoy.so.20.3.0'
linux-vdso.so.1 => linux-vdso.so.1 (0x00007fff70fa6000)
libGLESv2.so.2 => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff15b05b000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007ff15af7e000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff15af5e000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007ff15ad9e000)
/usr/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff15b2dc000)
I have gotten it working. Hopefully the following would provide assistance to anyone else encountering the problem.
I was setup using the main lirc configuration file, Lircd.conf. As a test, I switched to using the distributed toml keymap file (see /usr/lib/udev/rc_keymaps/*). To do so, remove the lircd.conf and create a file ~/.config/.rc_maps.cfg containing:
* * hauppauge.toml
So follow these instructions instead of the Lirc documentation.
I'm using an IR remote that is using the Hauppauge codes (PVR-250). Both a Hauppauge remote as well as a Harmony universal programmed as Hauppauge. The IR receiver being the built-in Odroid C2 one, so meson-ir.
The lirc.conf for the remote is the borg standard Hauppauge from the lirc website.
ir-keytable -t shows only one scan code per key. I also note that it immediately responds for each keypress, there is no waiting for the second keypress.
Using the nightlies on an Arm - Odroid C2, there is an issue for my remote following the upgrade to Lirc 0.10.2.
In short, Lirc 0.10.2 does not issue commands on each keypress. Instead, the key presses appear to be queued, with the queue being translated to commands on every 2nd key press. For example:
In terms of the nightlies:
Between those two builds is Pull lirc: update to 0.10.2 #6966
The Kodi debug log does not help since it only records when it receives the commands from Lirc, which is after the issue.
I misread the situation
Thanks for pointing it out.
Sorry. Looking back I realize I could have written that clearer.
So to clarify, for x86-64:
vpeter thanks. With the rebuild of the binary plugins, everything is good now.
I will note though that generic-legacy is required due to the dependencies on X11. GBM is missing the libraries so Kodi will just sit with the spinner spinning, no recognition that the libraries didn't load unless you check a debug log. For GBM, the missing are:
libXext.so.6 => not found
libX11.so.6 => not found
libxcb.so.1 => not found
vpeter does the "jre for bd-j menus" plugin need an update for the nightlies due to the libbluray version bump? i.e. do the .jar files need to match the libraries?
Thanks.
The builds versus hash in order of commit history are:
Build date | Hash |
20220720 (works) | 3a4dc81 |
20220723 (broken) | 0da8a26 |
20220723 (broken) | 0008ab5 |
In order of commit, the Pulls covering that range are:
3a4dc81 Pull #6717
1182c1a Pull #6721
13bb8f3 Pull #6724
06fd018 Pull #6715
2cc0585 Pull #6726
771b9b9 Pull #6470
f529cc9 Pull #6727
0da8a26 Pull #6729
0008ab5 Pull #6730
None of them are obvious as to breakage. If you were able to build Libreelec yourself, I would probably start by looking at #6727 as that appears to have triggered issues for others as well.