[alexmogavero]

Will probably be useful, but my english is too weak for that

Your English seems pretty good to me! However I could write it, but before we have to go through the HOW-TO:Submit a bug report.
I will read it as soon as I can and then get back here, however it would be nice, @Aux_, if you could help and read it as well.
Thanks!

[Aux_]

I hope the @popcornmix will preview here, he will help us guaranteed

[alexmogavero]

I could find the following bug reports: slideshow is very slow with big images. It is however very old and it is closed now. However the description is similar to what I observe. In my case I have never tried to load smaller pictures though.

[Aux_]

So now works slideshow.

1. I have put in Player settings -> Pictures -> Amount of time to display each image -> to 2sec
2. Randomise -> off
3. High quality downscaling -> on

After that I had reboot the RPi and slideshow works fine, I think Randomise does not work properly.

[alexmogavero]

I tried but it does not work for me. The slideshow is slow, it is fast only if I manually hit the next button on the remote.
Probably it is something linked with the fading effect.
Randomise does not seem to have any effect for me.

[Aux_]

@alexmogavero,

the only thing I had also changed was in Settings -> System -> Display -> Set GUI resolution limit -> 720, more I had not done.
Important is also I think reboot.
I use LibreELEC 8.0.2 - everything new installed

[alexmogavero]

Thank you. However I still cannot fix this issue, but I am not using LibreELEC, since I have Raspbian.
I have just completed the issue of a bug ticket here.
Let's see if anyone is able to help.

[Aux_]

Thank you. However I still cannot fix this issue, but I am not using LibreELEC, since I have Raspbian.
I have just completed the issue of a bug ticket here.
Let's see if anyone is able to help.

Well done, we have to wait and see what happens now.

[gert017]

With the Confluence skin instead of Estuary, it works better, but not optimally

[alexmogavero]

With the Confluence skin instead of Estuary, it works better, but not optimally

Thanks, I will try it.

[sawtsch]

Hi. 
I write through translator. Sorry for English
I have a Raspberry Pi 3 + Libreelec 8.2 + Kodi 17.5. 
And the problem is the same  - a slow slideshow.
It's better if u use a different skin, for example Mimic, Confluence
If you enable the debug log, the fps is displayed at the top of the screen. And it is noticeable that when using the Estuary 5-10 fps, only when you turn on the slideshow, and if the Mimic or Confluence 20-30 fps
I've already gotten used to Estuary, but it's not possible to view the photo
Why does the skin Estuary only affect the slideshow?
Maybe Raspberry Pi 3 it's not enough performance?

[Arsis50]

KODI 17.3 on Raspbian Jessie and 17.5 on Raspbian Stretch - the same issue.
Looking into logs, it seems that OMX rendering takes a lot of time per picture. I have tested it on bigger pictures from Smartphone (2048x1152) and also smaller ones from older digital camera (1600x1200). In both cases rendering takes about 6 seconds per picture. So, if one want faster timing, it is not working.

[Arsis50]

Some info from original alexmogavero DEBUG log:

Code:

22:41:27.767 T:1945993888   DEBUG: Loading the next image 0: /home/pi/Immagini/ArcobalenoWeb/2005-09-05_01.jpg
22:41:27.854 T:1741226928   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.image_decode input port 320 output port 321 m_handle 0x7231f8f0
22:41:27.855 T:1741226928   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.image_decode) - port(320), nBufferCountMin(2), nBufferCountActual(2), nBufferSize(81920), nBufferAlignmen(16)
22:41:27.860 T:1741226928   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.egl_render input port 220 output port 221 m_handle 0x72329030
22:41:27.861 T:1741226928   DEBUG: COMXCoreComponent::UseEGLImage component(OMX.broadcom.egl_render) - port(221), nBufferCountMin(1), nBufferCountActual(1), nBufferSize(15360) nBufferAlignmen(16)
22:41:27.875 T:1741226928   DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.image_decode handle 0x7231f8f0
22:41:27.877 T:1741226928   DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.egl_render handle 0x72329030
22:41:27.877 T:1741226928   DEBUG: DecodeJpegToTexture: decoded /home/pi/Immagini/ArcobalenoWeb/2005-09-05_01.jpg 640x480
22:41:27.878 T:1741226928   DEBUG: Finished background loading slot 0, 0: /home/pi/Immagini/ArcobalenoWeb/2005-09-05_01.jpg
22:41:36.609 T:1945993888   DEBUG: Image /home/pi/Immagini/ArcobalenoWeb/2005-09-05_06.jpg is finished rendering, switching to /home/pi/Immagini/ArcobalenoWeb/2005-09-05_01.jpg

Look at timestamps. It is obvious, that rendering for the first picture took about 9 seconds to finish. So, something here definitely seems working too slow. Is it "OMX.broadcom.egl_render"? Technically log says that its handle is closed only 17 ms after opening. Which process than is responsible for so long time to finish rendering? Maybe someone from developers can comment this?

[alexmogavero]

@Arsis50 , I noticed the timestamps as well, something is clearly not working for me. It might be e dependency on raspbian that is creating the problem. Still I think the issue mist be fixed in kodi. However for now we have no response to the bug report that I filed.

Anybody else knows updates?

[rasperic]

This issue persists:

RPi3
LibreElec 8.2.5
Kodi 17.6

Edit: It became much smoother after reboot and seems to depend on the resolution of the pictures.