[Buschel]

Oh, just disable Kodi settings > services > control > „Allow remote control … from other devices“.

[UlfSchmidt]

Oh, I wasn’t aware that this is a server setting. 🥺

With this setting the flickering playlist is gone, it is only once updated when the playback of the slideshow begins.
But it does not affect the performance in any way. And the connection indicator is still green?!

[Buschel]

Thanks for testing. This is a sign that building the playlist before playback might be the cause for the bad performance. Too bad you‘re not able to build the app on your own.

[UlfSchmidt]

Maybe I can try during my upcoming vacation to set up my own build environment…

[amasephy]

Tested entering folder with 8000 photos from windows box. It took a bit over 4mins 30 seconds. This is just using the app remote function to interact with Kodi server and simply entering the folder with the photos.

The lengthy dialog I get states “Scanning media information…
Loading media information from files…”

This is from a Samba connection.


Edit: Here’s a new one. I suspect this is a niche use case but I just discovered Kodi has airplay support. So I can stream music I have locally stored from my iPhone to Kodi server and actually control playback and everything as if I was playing back from Kodi natively.

There is an issue with the now playing g screen though. It gets the song info well enough but fails to acquire the artwork. However Kodi server displays the artwork on its now playing screen. Any chance the app could be updated to pull that art or is there no api for it?

[Buschel]

Let me test this (again). I somehow have the feeling I tested this way back, and the cover art was just not shared.

[UlfSchmidt]

Tested entering folder with 8000 photos from windows box. It took a bit over 4mins 30 seconds. This is just using the app remote function to interact with Kodi server and simply entering the folder with the photos.

The lengthy dialog I get states “Scanning media information…
Loading media information from files…”

Try the following instead:
Navigate to your pictures folder, but don’t enter it.
Then open the context menu on it.
The second entry should read “Recursive Slideshow” (or similar).
Select this entry. This should start the slideshow immediately.

Second question:
Is the media scan performed by Kodi each time you enter the folder? I think it’s cached internally and thus needed only once, like an implicit scraping…

[Buschel]

The "Recursive Slideshow" is what I use as well for my tests. But I am using 20k symlinks to the same file on the local machine. Though this for sure ends up in huge playlists and triggers the playlist updates, it will load the images quite quick as the file itself is local and might be cached. Maybe this is why I see most impact by debouncing and not when replacing Playlist.Add with Player.Open. Today I will connect a USB drive with images to see how this performs.

[Buschel]

Edit: Here’s a new one. I suspect this is a niche use case but I just discovered Kodi has airplay support. So I can stream music I have locally stored from my iPhone to Kodi server and actually control playback and everything as if I was playing back from Kodi natively.

There is an issue with the now playing g screen though. It gets the song info well enough but fails to acquire the artwork. However Kodi server displays the artwork on its now playing screen. Any chance the app could be updated to pull that art or is there no api for it?

Checked it. Kodi does share any thumbnail, fanart or art in this case. I can open an issue, but assume there is not much luck with it.

Edit: I guess the problem will be that the cover is received as image via airplay, and the Kodi API can only serve a path local to Kodi server or an internet URL. So Kodi would need to create thumbnails in this case, which would continuously change while playing material via airplay. Not sure, if this will be taken up. It is not straight forward.

[amasephy]

Thanks UlfSchmidt. That does indeed solve that problem. I started to suspect you were somehow avoiding the metadata loading. By loading the slideshow you are avoiding that.

Kodi does not appear to cache photos like it does with music and video. At least for me it doesn’t seem to happen. Anytime I launch Kodi it has to perform the same lengthy loading data routine if I open a folder with photos and the meta data and thumbnail caching options are enable on Kodi server.

Believe it or not there is a Kodi server setting to disable the exif and thumbnail loading. This only affects opening the folder with the images like I described. It does not affect the exif data on the apps now playing screen.

Kodi server seems to have the same limitation as the app when it comes to starting a slideshow from a root Photo source. I ended up loading the master directory as a source to test this.

When I did the recursive slideshow the playlist immediately went haywire. Constant bouncing. In this case the folder had 5,000 photos. After a few minutes the bouncing seems to have stopped.


Edit: here’s an interesting one. The recursive slideshow I started had a mix of pictures and videos. From a dump of my iPhone photo library. Slideshow works fine and plays both photos and video just fine. However, whenever a video plays from this the app playlist switches to the video playlist which is empty. Then when the next item is a picture it goes back to the photo playlist. Note that the photo playlist is where the videos are actually listed. Could be a Kodi server bug?

[Buschel]

When I did the recursive slideshow the playlist immediately went haywire. Constant bouncing. In this case the folder had 5,000 photos. After a few minutes the bouncing seems to have stopped.

You used the "debouncing" build?

[amasephy]

Yes I am still using the special build.

Note that when I was comparing the debounce build against the latest tf with the 8,000 photo “bouncing” issue without the special build the bouncing was like 100x more hyper if that makes sense.

So it doesn’t get lost in this thread I made an edit to my previous post with a new find.

[Buschel]

Edit: here’s an interesting one. The recursive slideshow I started had a mix of pictures and videos. From a dump of my iPhone photo library. Slideshow works fine and plays both photos and video just fine. However, whenever a video plays from this the app playlist switches to the video playlist which is empty. Then when the next item is a picture it goes back to the photo playlist. Note that the photo playlist is where the videos are actually listed. Could be a Kodi server bug?

That's exactly what happened to me as well. I even looked into details of the Kodi APIs response. Both the playerid (video = 1, picture = 2) and the playlistid (video = 1, picture = 2) change -- even though all files are part of the same playlistid (picture = 2). I need to admit that the App currently also treats both same, but the API does not even allow me to fix this.

[amasephy]

I just loaded in another recursive slideshow with around 9,000 photos and the bouncing just never ended.

So the one with 5,000 took a few minutes for the bouncing to stop but seems if it’s too big then it just chokes?

Is there a way to stream in more items as you navigate through the slideshow vs loading them all in at once?

I’m thinking of a C# thing where we can “take all” items from a database or more efficiently “take 10” items, process them, then request another 10. In take the method itself is called Take. Might not be possible with the Kodi api but figured I would ask.

[Buschel]

Back to using Player.Open: This also caused me so headache this morning. Just calling Player.Open on a directory does not work properly in case of images mixed with videos (this is how my usual vacation material is). In such case all files are added to the video playlist and all pictures are skipped until a video is reached. Pictures want a different type of command with the parameters "path", "random" and "recursive". But this only works for pictures. So we have the next special cases and I cannot tell, if this behaves same for all the supported Kodi versions ... Not sure yet if I really want to go there as there is a clear risk of regressions which will be hard to track down for older Kodi versions.