[Buschel]

Thanks, @amasephy, the videos help. I could now once (!) reproduce the cell height issue and will try, if my potential fix kicks in such situation. The stutter is also obvious, I also saw it now on my device once (only when the movies scrolled into sight). But this happened once, and not again after retrying. Feels like image reloading. Maybe the memory limitation kicks in and throws away the in-memory cache?

Edit: My fix, based on code review, seems to work. I can see it catches cell height mismatches. Using search, there are more of such incidents, but this happens also without. Most of this happens in the invisible area.

[amasephy]

Is the app set to limit memory use? My phone has 8gb of ram. Surely more than enough to run any intensive phone app. I will test this on my iPad and see if it stutters there too. That device has 3gb ram.

As for stutter I once again wonder if it’s a similar problem I have with movie collections. Library has grown to a size that causes problems. Speaking of which, I’m going to look at installing Kodi on another windows box and see if I have the same problem refreshing sync on movie collections.

Another thing regarding movie collections and global search - even when I only have a single movie from a collection it is showing up in global search but they do not show up in the dedicated movie collection library view.

UlfSchmidt, I love my 120hz display and the difference from 60hz is very obvious to my eye. 🙂 The stutter I experience makes the app seem like it’s running at 20hz though so significantly more noticeable.

[Buschel]

For the image cache there is a limitation defined. I will look it up later and share it here.

The Global Search view does not filter the movie sets to ignore 1-movie-only sets. This would even take longer to sync.

Maybe this ignore-1-movie-set settings is also causing the long sync times for you. Can you disable this setting in Kodi, reconnect the App and then resync the movie sets?

To be able to ignore the 1-movie-sets, the App needs to send an additional API request for each movie set. So, maybe the long time is caused by these additional requests to Kodi which Kodi needs to read from database and respond to.

[amasephy]

Ok I will try that.

Btw, I can scroll the entire global search list up and down and get no stutter. Now it only happens after performing a search as shown in video. And that happens consistently and after searching even repeatedly doing the same action. Has to be related to the search action. Also just tried disabling low power mode. Still stutters.


Edit: Toggling the ignore 1 movie sets fixed the issue. Now it’s an instant sync.

[Buschel]

Btw, I can scroll the entire global search list up and down and get no stutter. Now it only happens after performing a search as shown in video. And that happens consistently and after searching even repeatedly doing the same action. Has to be related to the search action. Also just tried disabling low power mode. Still stutters.

The search action itself is finished before the list is even displayed. I guess this might be an effect of the fact that with a list sorted by label/name, the neighboring cell types change and are updated more often while scrolling. How does Global Search behave without search, but sorted by "Name" instead of sorted by "Type"?

Edit: Toggling the ignore 1 movie sets fixed the issue. Now it’s an instant sync.

There were are. It is caused by the many JSON requests to server, each one a taking time to send/receive > perform a database query > send/receive > process the list.

[Buschel]

For the image cache there is a limitation defined. I will look it up later and share it here.

The in-memory image cache uses a quarter of the devices's RAM, but maximum 512 MB.

Code:

MIN(memorySize / 4, 512 * 1024 * 1024)

In the AppStore's metrics I can see that the 90% percentile max memory usage for iPhone (and also iPad when extrapolating from older metrics) is well below this. So in reality the the in-memory image cache is not limited for majority of users.

[amasephy]

Is there any reason to artificially limit the max to 512mb? Any chance you could do a TF and increase the max allocation?

Funny thing about the json overload with collections is that it fails almost instantly. That triggers the app connection to the server to disconnect and then automatically reconnect. Seems like there’s something more to it.


Edit: Sort global search by name causes stutter. But again, only while scrolling up. Scrolling down there is never stutter.

[Buschel]

Is there any reason to artificially limit the max to 512mb? Any chance you could do a TF and increase the max allocation?

Just good practice of defensive programming. A single App should not use up a major amount of the memory. Also, I saw crash reports where the image loading failed due to insufficient RAM. Therefore I limited the in-memory cache to not reach the system's boundaries and fail there.

Funny thing about the json overload with collections is that it fails almost instantly. That triggers the app connection to the server to disconnect and then automatically reconnect. Seems like there’s something more to it.

Well, the App in your case (I remember ou mentioned 60 movie sets?) shoots 60 JSON request in a loop, like a burst of requests. Maybe too much for your server.

Edit: Sort global search by name causes stutter. But again, only while scrolling up. Scrolling down there is never stutter.

Hmm, not 100% clear then ... What happens if you do not scroll down, but jump down via the index, then scroll up manually, then scroll down manually again?

[amasephy]

Scrolling down via index scrolling up and then back down and back up no stutter.

I’m not going to get too worked up over it. I don’t really use global search anyway outside of testing. If you can reproduce and determine a cause that can be fixed great. Otherwise we can probably let it be. I’d be a lot more bothered if this was an issue in the library views but those are totally smooth.

[Buschel]

Ok, let's keep it as is and move to more important stuff. 😊

[kambala]

@kambala, can you help with a hint where to look for regarding the "sticky section headers"? I am not clear why the stick headers don't work during search. Is this potentially happening as the searchbar is shown on top of the table?

sticky behavior is default for "plain" table style, searchbar shouldn't affect it in any way

[Buschel]

sticky behavior is default for "plain" table style, searchbar shouldn't affect it in any way

Ok, will try to figure out, if this is caused by table dimensions and its inset.

[Buschel]

1.16 build 4691.43

The next pure test build for not-yet merged changes. New, compared to last test build, is the fix for the wrong cell height and the stack rework for iPad (does not impact iPhone). 

• Improvement: Show sections with item type for search results in Global Search
  
• Improvement: Sort search results by ascending label
  
• Feature: Support searching year via the search field
  
• Bugfix: Ensure correct cell height in heightForRowAtIndexPath (NEW)
  
• Bugfix: Global Search might not show ratings for movies and TV shows
  
• Major rework of iPad StackScrollViewController (NEW)
  

[amasephy]

Cell re-use issue doesn’t occur anymore. 👍🏻

Cancelling search in global search returns to top. 👍🏻

Regression in view controller. Our friend the search bar makes an unwelcome appearance. Through a series of toggling you can make it appear offscreen. See video.

[Buschel]

Thanks for testing! No problems with the stack rework so far?

The unexpected visit of searchbar is the situation where it shows after coming back from fullscreen, even though it was not active before (around 0:21 in your video)?