[Buschel]

Thanks! I suspect 3 is also related to the strange Kodi behavior because normally you can’t have two active playlists but pictures defy that logic. Since music is playing the playlist seems to expect an elapsed time.

No Kodi issue on this one, this was caused by a simple logic mistake in the App code (https://github.com/xbmc/Official-Kodi-Re.../pull/1080). Fixed now, but not holding back the release.

Also forgot to mention. Until you actually “stop” a music playlist the photo art will not be displayed on the now playing screen and all navigation buttons won’t interact with the photo playlist. Probably working as expected though.

Yep, some Kodi logic I also was wondering about a while back. I am now used to this an just live with it.

Forgot to mention, with the text scaling. There does seem to be some little jitter only present in the text codec labels. Possibly as it’s making its transition between locations?

Yes, should be happening because the underlying label dimensions on locations are animated.

[amasephy]

Ok so this means your RC build is likely goi g to be final release build?

[Buschel]

The build is planned to be uploaded to AppStore for review. If there is a showstopper found, it will of course not be released. But small issues, especially if they existed since a while, will not stop the release. Small fixes can go into next.

[UlfSchmidt]

1.15 build 4451.42
This is a build for @amasephy and @UlfSchmidt purely for test reasons. It was provided as a test build before the 1.15 RC to keep the RC on top of TestFlight to receive more test depth. This test build addresses two main things:

1. …
   
2. Debounce playlist updates. This could improve the problems around creating slideshow playlists with huge amount of pictures.
   

Yes, so much better! Still sometimes some minor flickering, but at least it works much faster. Nevertheless I am still wondering why starting a slideshow from Kodi directly takes needs almost no time at all, while starting the same slideshow from the Remote takes a minute or longer (yes, it’s an edge case with over one thousand slides). Is there no API call that the Remote could use instead of queuing each single slide one after the other? I guess not, otherwise you already would have implemented it in that way, haven’t you?

Thanks for your continuous effort, @Buschel

[Buschel]

Yes, so much better! Still sometimes some minor flickering, but at least it works much faster. Nevertheless I am still wondering why starting a slideshow from Kodi directly takes needs almost no time at all, while starting the same slideshow from the Remote takes a minute or longer (yes, it’s an edge case with over one thousand slides). Is there no API call that the Remote could use instead of queuing each single slide one after the other? I guess not, otherwise you already would have implemented it in that way, haven’t you?

Well, in fact the App only uses three commands to play a movie, song, album or a folder of pictures: Playlist.Clear, Playlist.Add and Play. When starting a slideshow the App only sends a single command to add a folder to the playlist, no list of files or commands per picture. I cannot tell how Kodi handles this internally. Out of interest: can you share how it takes before and after the debouncing change?

Edit: I assume a factor iis that the App always bases playback on a playlist ("add folder to playlist", then "play playlist"), and Kodi might just use "play folder".

Edit 2: I just hacked something to use Player.Open instead of first filling the playlist. But my test system has not enough pictures to see a difference. Maybe I can add pictures and see, if the changed approach speeds this up. But: I am absolutely not sure, if such change can be done w/o breaking functionality especially for older Kodi versions.

Thanks for your continuous effort, @Buschel

Welcome!

[UlfSchmidt]

…
Out of interest: can you share how it takes before and after the debouncing change?
…

110 seconds for the 1746 images of my vacations in 2018 with Remote 4451.42
160 seconds with Remote 4465

So, in fact not that much faster, especially when compared to the three seconds in takes when started using Kodi's GUI directly ("Play folder")

[amasephy]

Just got around to testing the special build.

Queueing commands still happens.


Regarding the slideshows I finally see the bouncing issue. I loaded a folder with over 8000 photos. Before test build OOF that was bad. With special build everything is calm.

However there does seem to be a problem with your denounce fix. The playlist never clears. So I loaded in my 8000 photo playlist. Then I go to a different folder and start slideshow and it didn’t clear them out.

It takes suspending the app and then resuming to refresh the playlist. This causes the bounce effect which flushes and repopulates the playlist.

[Buschel]

Thanks. Will be hard to dig further into this w/o having a bigger amount of pictures on my test system. I assume you only watch the slideshow on your TV, not on the App?
Is impossible to queue the folder to the playlist from the Kodi UI? If so, does it also take very long?

[Buschel]

Queueing commands still happens.

How exactly did you test this?

However there does seem to be a problem with your denounce fix. The playlist never clears.

Works for me. But potentially this is caused by the excessive amount of files you added. On my test system I have about 20 pictures only.

[amasephy]

I could not reproduce a difference in loading the slideshow on Kodi server vs Kodi app. I guess I don’t understand the different ways to initiate them.

Btw, you should easily be able to reproduce the playlist not flushing. I did that test with two different folders with only 10 photos.

Also there seems to be some other problem with the bouncing. I switched and started a tv episode and came back to the slideshow playlist and now I can’t get it to stop bouncing… and there’s only 17 photos. It’s just going haywire. And even switching to a video playlist doesn’t stop the bouncing. It just goes right back to the photo playlist and keeps bouncing.

[Buschel]

Can you share a video of what you're seeing? I am really not having this problem. Which Kodi version you have running?

[amasephy]

Now I can’t reproduce. Maybe it has to do with loading that huge folder collection previously. I did take a video but it’s likely not going to be helpful since I can’t reproduce.

[Buschel]

Queueing commands still happens.

Just tested again with the TF build and my test system. It works as intended. Important is that the app recognizes the missing connection (= red connection status), which takes about 3 seconds. Button presses within this 3 s time frame (after the connection really dropped and until the app recognizes this) are still queued.

[Buschel]

Now I can’t reproduce. Maybe it has to do with loading that huge folder collection previously. I did take a video but it’s likely not going to be helpful since I can’t reproduce.

Ok, I will just try to get some more pictures on my test system.

[amasephy]

I can reproduce the playlist flushing issue. You do have to take some weird steps.

Basically select a folder and start a slideshow. For me I do this with remote on Kodi server. Go to a folder with photos, press up on remote to bring up context menu and select view slideshow.

Then use the right most pane remote control with the playlist visible on the middle pane which is mostly off screen now.

Use the right hand remote and navigate to another folder with photos. This time start a slideshow by simply selecting the photo and pressing select. This is an alternative method to starting a slideshow.

Now the playlist won’t have updated until you navigate away from now playing or suspend the app.

This works with folders that have only a few photos.


Btw you were absolutely right with the randomize being broke with photos even on Kodi server. You can toggle randomize from the context menu on Kodi server but it only works once. Even disabling it the playlist stays randomized. Very weird behavior.