[abga]

Still failing to replicate LE 9.2.4, OMX acceleration looks broken - both audio and video stuttering after 2-3 seconds of normal playback - debug log (same as before, no need to upload a new one) https://pastebin.com/cmbErrAa
Now I did build Kodi 18.8 for the rbpi target with:

Code:

export PATH="$PATH:/opt/java/bin"
CFLAGS="$CFLAGS -DEGL_NO_X11"
CXXFLAGS="$CXXFLAGS -DEGL_NO_X11"
mkdir /kit/kodi-slack-build/kodi-build/ && cd /kit/kodi-slack-build/kodi-build/
cmake ../xbmc-18.8-Leia -DCMAKE_INSTALL_PREFIX=/usr/local \
-DENABLE_INTERNAL_CROSSGUID=ON \
-DENABLE_INTERNAL_FLATBUFFERS=ON \
-DENABLE_INTERNAL_FMT=ON \
-DCORE_SYSTEM_NAME=linux \
-DWITH_CPU=arm1176jzf-s \
-DCMAKE_C_FLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft" \
-DCMAKE_CXX_FLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft" \
-DENABLE_AVAHI=OFF \
-DENABLE_PLIST=OFF \
-DENABLE_AIRTUNES=OFF \
-DENABLE_AIRTUNES=OFF \
-DENABLE_UPNP=OFF \
-DENABLE_NEON=OFF \
-DENABLE_VDPAU=OFF \
-DENABLE_VAAPI=OFF \
-DCORE_PLATFORM_NAME=rbpi \
-DCMAKE_PREFIX_PATH=/opt/vc

Outputs of both cmake and ldd from the resulting kodi bin to be found at:
https://pastebin.com/aaG6GThk

Issues:
- resolved -  I had to temporarily make /usr/include/GLES3/ unavailable during the build (it's my old system mesa), because /xbmc-18.8-Leia/cmake/modules/FindOpenGLES.cmake found it, enabled the -DHAS_GLES=3 flag and the compilation crashed with: usr/include/GLES3/gl3.h:899:2: error: 'GLsync' does not name a type

- unresolved: Failed to connect to ftp.halifax.rwth-aachen.de port 443: Connection timed out - please try to remove those guys from your mirrors. I'm always having issues with their servers in the last years (other repos unrelated to Kodi) - they're unreliable - playing around with the firewalls? rate limiting? ...

- unresolved - apparently I have no "PLL Adjustment to maintain audio/video sync" option in Kodi Audio Settings Menu (Expert Mode) and this line was also not available in my other build attempts. Don't know why & what enables it. I also fear that this could be one of the causes of my playback issues - is it enabled by default?

- unresolved - OMX acceleration plays 2-3 seconds fine and then starts to stutter - both audio and video, even for big buck bunny h264 at 640x480 !!! played locally. I also noticed a weird warning flashing a few times in the upper right corner on the screen - something like: "the source is too slow for playback!", while playing a mpeg4 H264 1080p (very lossy - high compression) file from a local ftp repository. That was weird, apparently a 50-60Mbps FTP stream is not enough to feed a 1-2Mbps video stream to the omxplayer and this is just confirming my suspicion - some buffering issues: bottleneck/excess in Kodi - e.g. Kodi "trying to kill" the poor omxplayer, feeding it with excessive data.
The VideoPlayer (WawWawPlayer) with MMAL acceleration plays ok all sources, except that the audio waw waw makes it useless.
I did all the tests on the Pi2B build system running armv6 code (armv6 Linux distro), only the kernel was armv7 (needed for booting) and I never saw the CPU exceeding 25-30% usage (load spread at 4-6% on all 4 cores). The same is actually true for the PiZero, CPU is not loaded more than 30-40% for local playback, the only higher load for the PiZero (Kodi 17 and LE 9.2.4) is when playing DVB streams at 1080p with OMX and that doesn't exceed 75-80%.

- unresolved - my PowerManager.cpp is still not working, the PM code in Kodi 17 was simpler... but this should be maybe a topic for another thread

Code:

 diff PowerManager-orig.cpp PowerManager.cpp
55c55
<   int defaultShutdown = m_settings->GetInt(CSettings::SETTING_POWERMANAGEMENT_SHUTDOWNSTATE);
---
>   int defaultShutdown = POWERSTATE_SHUTDOWN;
62c62,63
<       if (g_application.IsStandAlone())
---
> // comment this to enable shutdown menu
> //      if (g_application.IsStandAlone())
84,90c85,94
<       if (!CServiceBroker::GetPowerManager().CanPowerdown())
<       {
<         if (CServiceBroker::GetPowerManager().CanSuspend())
<           defaultShutdown = POWERSTATE_SUSPEND;
<         else
<           defaultShutdown = CServiceBroker::GetPowerManager().CanHibernate() ? POWERSTATE_HIBERNATE : POWERSTATE_QUIT;
<       }
---
> // add this to enable shutdown menu
>         defaultShutdown = POWERSTATE_SHUTDOWN;
> // comment this to enable shutdown menu
> //      if (!CServiceBroker::GetPowerManager().CanPowerdown())
> //      {
> //        if (CServiceBroker::GetPowerManager().CanSuspend())
> //          defaultShutdown = POWERSTATE_SUSPEND;
> //        else
> //          defaultShutdown = CServiceBroker::GetPowerManager().CanHibernate() ? POWERSTATE_HIBERNATE : POWERSTATE_QUIT;
> //      }
99c103,108
<   if (CanPowerdown() && m_instance->Powerdown())
---
> // comment this to enable shutdown menu
> //  if (CanPowerdown() && m_instance->Powerdown())
> // add :
>  bool blabla = true;
>  if (blabla)
> // done add
120a130
>
139c149
<   return m_instance ? m_instance->CanPowerdown() : false;
---
>   return m_instance ? m_instance->CanPowerdown() : true;

This is how I build FFmpeg externally - shared:
- source  https://github.com/xbmc/FFmpeg/archive/4...8.4.tar.gz
- applying only this patch: https://github.com/LibreELEC/LibreELEC.t...ions.patch
- with: patch -p1 < patches/ffmpeg-001-pfcd_hevc_optimisations.patch
(also tried to add these other patches - useless in my case - and they didn't help:
https://raw.githubusercontent.com/LibreE...-ren.patch
https://raw.githubusercontent.com/LibreE...-one.patch
https://raw.githubusercontent.com/LibreE...ches.patch
)
- configuring & building:

Code:

./configure --extra-ldflags="-L /opt/vc/lib/" \
--extra-cflags="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft" \
--extra-cxxflags="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft" \
--extra-libs="-lbcm_host -lvcos -lvchiq_arm -lmmal -lmmal_core -lmmal_util -lvcsm" \
--target-os="linux" \
--prefix="/usr" \
--disable-static \
--enable-shared \
--enable-gpl \
--disable-version3 \
--enable-nonfree \
--enable-logging \
--disable-doc \
--disable-debug --enable-stripping \
--enable-pic \
--enable-optimizations \
--disable-extra-warnings \
--disable-programs \
--enable-avdevice \
--enable-avcodec \
--enable-avformat \
--enable-swscale \
--enable-postproc \
--enable-avfilter \
--disable-devices \
--enable-pthreads \
--enable-network \
--disable-gnutls --enable-openssl \
--disable-gray \
--enable-swscale-alpha \
--disable-small \
--enable-dct \
--enable-fft \
--enable-mdct \
--enable-rdft \
--disable-crystalhd \
--disable-vaapi --disable-vdpau \
--enable-runtime-cpudetect \
--disable-hardcoded-tables \
--disable-encoders \
--enable-encoder=ac3 \
--enable-encoder=aac \
--enable-encoder=wmav2 \
--enable-encoder=mjpeg \
--enable-encoder=png \
--enable-hwaccels \
--disable-muxers \
--enable-muxer=spdif \
--enable-muxer=adts \
--enable-muxer=asf \
--enable-muxer=ipod \
--enable-muxer=mpegts \
--enable-demuxers \
--enable-parsers \
--enable-bsfs \
--enable-protocol=http \
--disable-indevs \
--disable-outdevs \
--enable-filters \
--disable-avisynth \
--enable-bzlib \
--disable-lzma \
--disable-alsa \
--disable-frei0r \
--disable-libopencore-amrnb \
--disable-libopencore-amrwb \
--disable-libopencv \
--disable-libdc1394 \
--disable-libfreetype \
--disable-libgsm \
--disable-libmp3lame \
--disable-libopenjpeg \
--disable-librtmp \
--disable-libtheora \
--disable-libvo-amrwbenc \
--disable-libvorbis \
--disable-libvpx \
--disable-libx264 \
--disable-libxavs \
--disable-libxvid \
--enable-zlib \
--enable-asm \
--disable-altivec \
--disable-symver \
--disable-neon \
--enable-rpi \
--enable-libass

Finally, I removed the local system mesa package and checked the links with ldd /usr/local/lib/kodi/kodi-rbpi - compared with the previous output and found no changes, meaning, local mesa is not used and doesn't represent a cause for the issues reported. Launched Kodi and experienced the same playback issues.

Are there any Kodi 18.x code patches LE is applying that I'm not aware about?

Any other hints appreciated!

[popcornmix]

Perhaps you are missing https://github.com/LibreELEC/LibreELEC.t...age.mk#L15

[abga]

Perhaps you are missing https://github.com/LibreELEC/LibreELEC.t...age.mk#L15

Why didn't you say so before? Left me here struggling to make the "incompatible" official Kodi 18.8 code work on the Raspberries ... 
Thanks for pointing me to your source code adaptations, not sure why I missed that line in the LE Makefile.
Will try to build https://github.com/popcornmix/xbmc/archi...eia.tar.gz

But first I'd like to take some time and find a way to properly hack PowerManager.cpp. It takes ~ 4 hours to build Kodi on a Rpi2B with 3 make jobs and I'm trying to spare the SDCard from too much hammering, already performed around 6 Kodi compilations on it, including several other FFMpeg & kernel ones. I could attach an external HDD, did it before, but it's not really an option now with my available space/power supplies ...

[abga]

Eureka!

After a few failed builds, I finally managed to get  https://github.com/popcornmix/xbmc/archi...eia.tar.gz up and running, actually replicating LibreELEC 9.2.4
Issues encountered and resolved:
- the "friends" at ftp.halifax.rwth-aachen.de broke the build several times, at least it was in the beginning, easy to restart
- then I stumbled upon an issue with BluRay, down at 84% in the build, at least I wasn't the first:
https://forum.kodi.tv/showthread.php?tid...pid2760289
Learned that -​DENABLE_BLURAY=OFF is not supported anymore - got: CMake Error: The source directory "/kit/kodi-slack-build/kodi-build/-​DENABLE_BLURAY=OFF" does not exist.
Just uninstalled the libbluray-0.9.3 package,restarted the build and built it successful. I don't need BluRay and didn't bother building and patching popcornmix's special bluray package.

Now I get all local content playing perfectly fine with omxplayer and MMAL Bob de-interlacing, same as LE 9.2.4 and honestly, same speed and GUI snappiness as with Kodi 17.x
Besides, I have a few FFmpeg 4.0.4-Leia-18.4.tar.gz builds from my previous attempts and one of them is a pure unpatched build where I used --enable-mmal \ --enable-omx \ --enable-omx-rpi for enabling the acceleration. That build works perfectly fine for my needs, haven't noticed any difference in performance on both OMX and MMAL accelerated playback.
This is the good news!

The bad news is that my build of Kodi18.8 together with LE 9.2.4 (sorry for not paying attention) is experiencing a hiccup when playing DVB streams with OMX, regardless of quality SD/HD. It's the same behavior I had with the official Kodi 18.8 code before on all sources - local & DVB. The official Kodi 18.8 played 2-3 seconds, got the hiccup, it recovered for a few more seconds and then the video & audio stuttering started and never recovered.
newclock5_18.8-Leia only gets the hiccup when playing DVB streams through pvr.hts, but it recovers.
The DVB playback in newclock5_18.8-Leia (also in the official Kodi 18.8) is instant - compared to Kodi 17.x, where I always need to wait a few milliseconds when switching channels, watching the buffering circle filling.
newclock5_18.8-Leia start playing instantly and perfectly for 2-3 seconds and then it gets the hiccup that lasts for another 2-3 seconds after which it recovers and continues playing perfectly.
I investigated this several times by observing the system with both htop and bcmstat and couldn't notice any spikes in CPU/memory usage, quite the contrary, the CPU usage is very low during the hiccup.
For instance, on the PiZero when staring playing a 1080p DVB stream, the CPU jumps and stays at ~80-90% for the first 2-3 seconds and then during the hiccup drops at 30%, recovering again at 80-90%. On the Pi2B, when staring playing a 1080p DVB stream, the CPU usage is around 30%, then during the hiccup it's almost idle, recovering back at ~ 30%
I believe it's something in the Kodi code and clearly not a performance issue. Maybe the fixes from the newclock5_18.8-Leia code should be also applied for the pvr.hts input, just guessing.

Now to the facts. I deliberately used the Pi2B for the test, just to avoid any confusion related to the "low performance" of the Pi Zero, loaded the newclock5_18.8-Leia build on it together with the LE 9.2.4 firmware and here is the debug log with the hiccups on DVB - pvr.hts (enabled also the tracing-debug in the pvr.hts addon):
http://www.mediafire.com/file/zgvcatwlc8nrjv5/file
(cannot put it on paste.bin - it exceeds 512KB)
- at - 2020-09-26 23:52:27.724 T:1877996512 - started playing BBC World HD - 1080p
- at - 2020-09-26 23:52:42.903 T:1877996512 - started playing EURONEWS SD - 576p

Some short videos (crappy quality with an old Android phone) recording the events from the debug-log:
- HD-1080p-DVB-Stream.mp4 -
(never mind the bad audio after recovering, it's the analogue audio broken in the firmware for almost 3 years now - https://www.raspberrypi.org/forums/viewt...p?t=195178 )
http://www.mediafire.com/file/0hqbucyy4z3630f/file
- SD-576p-DVB-Stream.mp4
http://www.mediafire.com/file/nvur8m94r21pk2p/file

Note that the video playback (bottom counter) starts at -6 ( why ?) and then it plays OK up to -3, then the hiccup occurs, and then at 0:00 it starts playing normally and the counter is increasing. I pressed OK on the remote to bring up the status bar.

Just in case my Kodi settings are needed - pasted the guisettings.xml (it's the same as in LE 9.2.4):
https://pastebin.com/vR4vvWt3

[abga]

bump!

Has anyone got the chance to look over the issues & info I provided in my last post?
Was wondering if the DVB playback issue is only pvr.hts addon related - maybe it needs some pre-buffering. Might start a thread in the appropriate section.

Thanks!

[noggin]

Are those DVB streams 1080p and 576p rather than 1080i or 576i?  The only places I know using 1080p (*) and 576p for DVB broadcast are using h.265/HEVC (which is a non-starter for a Zero).   All the mainstream stuff using h.264 or MPEG2 is still 1080i or 576i?

(*) BBC PSB3 on Freeview HD uses dynamic 1080i25/1080p25 encoder switching - but is relatively unusual in doing that I believe (it switches encoder modes at GOP level AIUI)

[abga]

There are usual DVB-S & DVB-S2 & & DVB-T2 & DVB-C streams, in SD (MPEG2), HD-Ready (MPEG4 - 720p) and Full HD ((MPEG4 - 1080p - 25fps) format and no HEVC. Some of the HD are indeed interlaced with different types of interlacing, none of which have issues playing properly under Kodi 17 - OMXPlayer on PiZero. I bought MPEG2 licenses for all of my Pi boards and the test I ran in post #4 was on Pi2B and not on a Pi Zero, just to avoid any performance related confusion (and potential useless arguments). Nevertheless, the same behavior is to be observed on PiZero too and since Pi2B cannot do the job properly, I suspect neither does a Pi3B.

It's something in the Kodi / pvr.hts code, but since this behavior was observed with all media playback under the Raspberry Pi "incompatible" official Kodi 18.8 source, I'm inclined to believe that something in the Raspberry Pi "compatible" newclock5_18.8-Leia needs to be additionally patched for the DVB - pvr.hts input playback.

[abga]

bump