[Buschel]

The situation of running through the playlist without playing happens as well when adding something to a playlist which cannot be played by the playlist type, e.g. adding videos to a picture playlist (not using the slideshow command). So, you definitely face a problem on Kodi server. I will not further dig into this. Best for you will be to remove the video splash.

[UlfSchmidt]

Thanks for looking into this. Removal of the welcome video is not an option, as I use it to verify that passthrough of object-oriented audio like Dolby Atmos is still working correctly. Often enough, by some update or patch, either Kodi or the Nvidia Shield lost this setting somehow. And I use wireless speakers that also sometimes lose connection to their base. So, I play a short dts X trailer as welcome video to check that my audio setup is still working properly.

[amasephy]

Interesting tactic for verifying passthrough is working. I did not even know intro movie was a thing in Kodi.

I’ve had the same problems with passthrough breaking with windows and Xbox based Kodi servers. At first I was so excited about passthrough giving us the uncompressed audio formats but I eventually gave up on it. Everytime I invited company over is exactly when passthrough broke and I would encounter no audio playback for a movie. A shame.

[Buschel]

Another quite easy way would be to add such trailers to Favorites and just play them after any update of software or hardware. But I admit that playing it every time is easier.

@UlfSchmidt, what happens, if you start the app before Kodi and then then just move to another playlist (in the app) while your splash videos runs?

[Buschel]

1.16 build 4798.42

A new test build to collect feedback on two changes: rework of wakeup and rework of image cache.

Rework of wakeup
The app will now always use the iOS framework signal applicationDidBecomeActive to start the (re-)connection attempts and heartbeat. This should resolve the issue that sometimes "connection lost" message is shown after wakeup. From measurements I could see this only adds a delay of about 0.2 s.

Rework of image cache
The image cache pre-scales images, but always kept the original images' aspect ratio. If the aspect ratio (e.g. 300x600) did not match to the target dimension (e.g. 150x150), the pre-scaled image was maintaining too many pixels (e.g. 150x300). This caused higher flash and memory consumption and also could potentially impact the scroll performance as additional scaling would be needed from the UI functions. This test build now pre-scales images to the target resolution and aspect ratio. Another change reduces the memory consumption of the image cache to 100-130% of the configured size. Before, 200% were used.

For test purposes a setting was introduced: "Images decompressed to RAM". If enabled (which was the default before this test build as well), there is an additional step when loading the images to RAM for the first time. This uses the least memory. If disabled, there is no additional step when loading images. In this case, the memory consumption for the image cache is higher (by the amount of the flash image data which was read for each cached image). As I am not clear on any performance impact of the "decompression" feature, I made this an option for testing.

Important: You need to delete the image cache (either via settings and restart of app, or via fully deleting the app from device). If not done, the image cache (flash) still keeps the images with wrong aspect ratios.

[UlfSchmidt]

@UlfSchmidt, what happens, if you start the app before Kodi and then then just move to another playlist (in the app) while your splash videos runs?

Sorry, don’t exactly get what you’re asking for. “Move to another playlist” simply shows that playlist (music or pictures)?

Rework of wakeup

This change didn't leave any noticeable impression. Maybe I am not sensitive enough to recognize 200 ms?

Rework of image cache

I also don’t see any noticeable difference between the previous version and the current version of the App here, maybe since all my artwork already matches the aspect ratio as defined by Kodi?

[Buschel]

Sorry, don’t exactly get what you’re asking for. “Move to another playlist” simply shows that playlist (music or pictures)?

Ok, let explain in more detail. My understanding is that your Kodi server plays startup video, and when the app is started while this is playing, the app shows the "video" playlist (bottom left of iPad screen). My ask is: start the app before you start Kodi. Then start Kodi. While the startup video is played, please select the "music" playlist. This triggers a command to Kodi to retrieve the "music" playlist. I am curious if this simple action causes the hassle you're experiencing.

This change didn't leave any noticeable impression. Maybe I am not sensitive enough to recognize 200 ms?

Main worry would be any unforeseen issue with connection/re-connection. If you do not see any, we're good.

I also don’t see any noticeable difference between the previous version and the current version of the App here, maybe since all my artwork already matches the aspect ratio as defined by Kodi?

You would for sure have such situation when entering the Live TV or Radio menu and scroll through all stations list grid view.

[amasephy]

Thanks for your hard work on this. Reduced ram usage in the iOS world where users have no task manager to visually see this will always go unnoticed and thus unappreciated. Respect to you for working on invisible features. 👍🏻

Here are my findings.

Stutter is gone but I was only experiencing it before you made the change to clearing the search. Before clearing the search on global search left you scrolled down in the list. Several test flights ago you made it reset to the top.

Too early to tell about connection toast but will keep an eye on it for a couple of days.

Two new things I would like to report.

1)
Regarding connection notification - current you have it paused when viewing the main menu screen. This is good. I’d like to propose another scenario it should be paused on.

If you go into the Add Host screen it probably should be paused there too.


2)
Potential race condition or some other shenanigans going on.

I start party mode to load up some songs. Then I long press to bring up action sheet. At the top of the action sheet should be three lines - title, album, artist.

Currently it’s also prepending the artist name to the title. This is redundant.

But it gets weirder. Sometimes it doesn’t prepend the artist name. When skipping to next track and checking the action sheet it changes. I captured video to showcase this.

At first Bob Dylan isn’t prepended. Then it gets prepended. Note: When first starting party mode all tracks have artist prepended. Only when tracks start playing and advancing to the next track does it get randomly weird.

[Buschel]

The invisible improvement (memory consumption improvement) should help to reduce the probability of iOS stopping the app in background where there is system pressure to reduce memory usage. 😉

1) Will review the situation an decide.
Edit: For now I will keep it as is. The toast message does not overlap with the text fields. It is still possible to move the pane to get back main menu. Only difficulty can be to move back to server list.

2) Yep, saw the same (but less often). This is just another Kodi server thing. What you see is what Kodi provides back as "label". I looked into options to improve this by using "title" instead of "label" when possible. Will raise a PR once finished.
Edit: https://github.com/xbmc/Official-Kodi-Re.../pull/1184

[Buschel]

Stutter is gone but I was only experiencing it before you made the change to clearing the search. Before clearing the search on global search left you scrolled down in the list. Several test flights ago you made it reset to the top.

If an old build, which does not scroll to top, is still available via TestFlight, there is a way to test. You can just delete the image cache and refill it with the latest TF build. The resizing is done before writing to flash, so this will persist. After refilling the cache (just by scrolling through all items in the view you use for testing), you can install the old TF build and the check, if the stuttering is gone. This would be the proof that the scaling did the trick. If not, there is still something else ...

[amasephy]

I just tested the cache as you described and I got massive stutter in global search just by using index to scroll down and then start scrolling up at an arbitrary point.

Doing the same action in latest TF there is no stutter.


So something resolved the stutter in newer build.


Btw, using the latest image cache with any previous TF causes global search pane to populate slowly. With latest build it’s instant.

Edit:
Just went through the TF builds. Global search stutter actually seems to have disappeared at build 4691.43.

At 4691.42 and earlier I get massive stutter when scrolling up.

[Buschel]

Btw, using the latest image cache with any previous TF causes global search pane to populate slowly. With latest build it’s instant.

This is unexpected. Didm you possibly just see this on the very first time you enter this view after installing a different version? In this case the data is freshly synchronized. Any later attempt is coming from cache (feeling like an instant response), and you would need to pull-to-sync to update it.

Just went through the TF builds. Global search stutter actually seems to have disappeared at build 4691.43.

Interesting! Then I guess "Bugfix: Ensure correct cell height in heightForRowAtIndexPath" is did this. This definitely impacted the cell height (and by this also thumb heights) for re-used cells.

But it seems that no other negative impact was observed by the image cache changes in the latest TF build -- which sounds great.

As you do not see any stutter anymore, did you "play" with decompression setting at all? Personally, I tend to deactivate it. This will consume some more RAM compared to having it enabled, but there is no superfluous image processing done anymore. I am just not sure, if this somehow causes "more work" in the UI image processing when showing the images.

[amasephy]

Slow loading global search seems to be what you describe. Only first time.

No negative side effects observed with the various settings you referenced.


Btw found a regression from build 4691 onward. Global search sort by is not persistent when entering that view. It always resets to type. Before this build it persisted. The other library views still persist their sort by listing.

[Buschel]

Btw found a regression from build 4691 onward. Global search sort by is not persistent when entering that view. It always resets to type. Before this build it persisted. The other library views still persist their sort by listing.

Oh yes, this was a nasty one. This happened as a side effect of a long-wanted bigger rework of the main menu structure types. I have two ways to fix this, need to think of what is the more appropriate one.

[UlfSchmidt]

…
Ok, let explain in more detail. My understanding is that your Kodi server plays startup video, and when the app is started while this is playing, the app shows the "video" playlist (bottom left of iPad screen). My ask is: start the app before you start Kodi. Then start Kodi. While the startup video is played, please select the "music" playlist. This triggers a command to Kodi to retrieve the "music" playlist. I am curious if this simple action causes the hassle you're experiencing.

The behavior is exactly the same: at the end of the video, the playlist view is set back to movies and remains there when I start any song.

You would for sure have such situation when entering the Live TV or Radio menu and scroll through all stations list grid view.

I gave up using Kodi for Live TV (no longer watching linear television at all) and never used it for radio reception.