+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Supplementary Tools for Kodi (https://forum.kodi.tv/forumdisplay.php?fid=116)
+---- Forum: Kodi Remote for iOS Official Forum (https://forum.kodi.tv/forumdisplay.php?fid=193)
+---- Thread: Beta Testflight access to beta version (/showthread.php?tid=359717)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
RE: Testflight access to beta version - Buschel - 2024-01-16
This should not happen, and I am also not seeing this kind of behavior on my end (latest App version and Kodi 20.3). Which Kodi version you test with? And in which view exactly (the details view, or the library view with the list/grid) you observe this?
Edit: You could also double check by testing with the last 1.13.1 TF build again.
RE: Testflight access to beta version - UlfSchmidt - 2024-01-16
(2024-01-16, 22:58)amasephy Wrote: I believe this is one of the things you requested feedback on with the latest TestFlight…
I’ve noticed the image cache seems to be getting reset all the time now. By that I mean when navigating to the movies tab the cover art is constantly having to be downloaded by the app. Previously you had to fight with the app to get it to refresh the artwork, now you cannot avoid it.
Anyone else noticing this? Happens with movies, tv and music artwork.
You are right. Now that you mentioned it, I recognize it too. But image loading is so fast, you really have to check for it explicitly. That’s why I didn’t really notice it until now.
Only difference in my observations is that the cache is only reset at any cold start of the app, not when just switching between different tabs.
Edit: Kodi 21 beta 2, app 4181 (for @Buschel )
RE: Testflight access to beta version - Buschel - 2024-01-16
I am a bit lost now. I really cannot see such behavior. I even rolled back to lost 1.13.1 TF build. The image cache is still valid even when switching app versions. And I cannot really imagine this is an effect of limiting the in-memory cache to 512 MB, which is still quite big.
And pls remind: 21 Beta 2 still has problems with image cache on Kodi side. Not sure, if this impacts the user experience. Would really be good to retest with App version 1.13.1 and/or Kodi 20.3.
RE: Testflight access to beta version - amasephy - 2024-01-17
I believe it actually started a few test flights ago but at the time I had been tinkering with the image cache reset.
Initially I thought it was because I had enabled “reset cache on next start” but that disables after the next start so for the longest time I thought I was being lazy in not toggling it. Imagine my surprise when I finally went to check and it was toggled off.
I’m still on 20.2. Xbox joys. Didn’t know 20.3 was out.
It does refresh the images quickly but it’s really noticeable in TV banners art. It’s probably more noticeable for me because of the extremely high resolution images acquired through Ember. Most of my poster art is 2000x3000. This is way larger than what Kodi scrapes natively.
If you scroll in Movies you will quickly bypass the art that has loaded in though. I do not find it difficult at all to see movies/shows before art has loaded in.
Noticed in library views and art type does not matter.
Same issue in Global search. In fact with global search which you would think uses the same poster art from other library views still has to load in its own set of art. Not sure if this is by design or not. They look really similar to me.
I will have to closely monitor when it resets what my actions were. I am not sure if it’s only on cold app starts.
I can say if I were to explicitly force all the images to cache, then suspend the app and come back in the images will still be cached. My experience has been watch something in the evening. Then the next day watch something and notice the cache has been wiped out.
RE: Testflight access to beta version - UlfSchmidt - 2024-01-17
(2024-01-16, 23:48)Buschel Wrote: I am a bit lost now. I really cannot see such behavior. I even rolled back to lost 1.13.1 TF build. The image cache is still valid even when switching app versions. And I cannot really imagine this is an effect of limiting the in-memory cache to 512 MB, which is still quite big.
Aha! My image files sum up to 535M for albums, 148M for TV series and 186M for movies, and I even don't use any high resolution images. Maybe then the cache size limit is in fact the cause for this new behavior and it's by intention?
RE: Testflight access to beta version - Buschel - 2024-01-17
(2024-01-17, 06:21)UlfSchmidt Wrote: Aha! My image files sum up to 535M for albums, 148M for TV series and 186M for movies, and I even don't use any high resolution images. Maybe than the cache size limit is in fact the cause for this new behavior and it's by intention?Let me be more precise: 512 MB is the limit for the in-memory cache (= RAM), not for the storage cache (= flash). Memory caching comes on top of storage cache to avoid loading and decoding an image from cache to make scrolling through list smoother. It should not impact storage cache at all -- as per documentation --, but I will look at this again. The images cached in storage (to my knowledge) are invalidated after 1 week automatically to free up storage by default. The default was never touched.
During test I could reach >1 GB usage when entering the details view for each movie, TV Show and album as they are using high resolution images for the covers and the background fanart. This was excessive.
(2024-01-17, 04:52)amasephy Wrote: I believe it actually started a few test flights ago but at the time I had been tinkering with the image cache reset.Any chance you can narrow this down further? Older TF builds all went into the official release.
(2024-01-17, 04:52)amasephy Wrote: Initially I thought it was because I had enabled “reset cache on next start” but that disables after the next start so for the longest time I thought I was being lazy in not toggling it. Imagine my surprise when I finally went to check and it was toggled off.If the cache-reset flag is enabled by you, the cache is removed during next startup and then then flag is set back to off by the same process. This is why you would usually see it set to off.
(2024-01-17, 04:52)amasephy Wrote: I’m still on 20.2. Xbox joys. Didn’t know 20.3 was out.20.2 is also good. Even though there was a fix in Kodi around image caching. But this will not impact what you are seeing.
@amasephy, to summarize your other statements from what might be related:
- you saw this in earlier TF builds
- you see this in the library view (scrolling through) -> this will cache scaled down images to RAM and to storage
- you have large images -> load and processing will take longer, but once cached they will be cached in small size and load quite quick.
- you see the files cached after loading once, then put the app to sleep and waking it up again -> good
- you see image reload after 1 day -> I will recheck the cache cleanup
- you see global search image to reload even though already cached before in the "regular" library views -> should be same, I am not seeing this on my side...
Do you really see re-loading the images from the server? This would take quite long as the images are so huge on your side. Or do you see a reload of the images from the storage cache, which would be quite, but could be noticeable if you scroll through lists quick. I assume you see the first, in this case:
- cache could be outdated -> I can look into this in more detail and check when outdating happens
- possibly the URL to the image changed (new IP?) -> the image URL holds the full server address
I will think about this in more depth. Any other observation on this mightnhelp to narrow this down further.
RE: Testflight access to beta version - amasephy - 2024-01-17
Your summary of my statements seems correct.
I am not sure if it’s really pulling data from server. What I see is a placeholder graphic until the artwork loads.
It’s generally really fast to load in the art. However, it’s obviously annoying when this is happening all the time needlessly.
I will go back a few test flights and try to narrow it down. Will take a bit though… seeing as I don’t know the exact trigger to make it happen… timing vs cold boot.
Also, iOS 17 became a thing in between those releases. Could that have anything to do with it? My guess is that it started at least 3-4 test flights ago. Not long after you asked me to reset the cache with that flag in the settings.
I scrolled back in the forum and I “think” it may have started with your fixes for the low resolution Now Playing artwork. Thats when you asked me to clear the cache manually.
I will go back to prior to this test flight and see if I can confirm. Hopefully that release is still available.
Just to confirm: no up changes. Nothing should be invalidating the cache that I can tell. Thinking back to the many years of using the app I never experienced artwork placeholders once the images were initially cached.
RE: Testflight access to beta version - Buschel - 2024-01-17
I don't think this is an iOS 17 issue. I would rather expect the invalidation (after 1 week) is kicking in too fast, or you see the effect of the reduced in-memory (RAM) caching. Clearing in-memory cache only happens on iOS-warning in the framework method applicationDidReceiveMemoryWarning or when the app is restarted. The in-memory cache drops older cached images, if the 512 MB limit is reached.
Is the re-loading you experience taking as long as loading the covers very first time, or is it a lot faster (but still visible)? Just trying to figure out, if you see a real reloading from server, or if you see the reloading from internal storage (which is just not as fast as taking it from RAM).
If you do not see this issue already with older builds, I could ask to trigger one or two test builds with few rollbacks to see, if there was a certain change causing this.
RE: Testflight access to beta version - amasephy - 2024-01-17
It does not take long to reload the images.
Scrolling quickly in Movies library allows me to view placeholders.
TV shows library initial view the delay is longer and there’s only a few banner arts even in there. Seems like movies would be slower but it’s TV shows.
I’ll capture some videos later of my experience.
I do not believe this has anything to do with the memory cap introduced.
I am almost certain the problems started when you put in the fixes for the low resolution now playing art. Though this does not make sense and your code fix likely shouldn’t have affected the cache at all.
RE: Testflight access to beta version - Buschel - 2024-01-17
Looking at the code which fixed lowres images I cannot see any impact to the cache behaviour at all. It just takes care to handle parallel attempts to save images of same origin but different target resolution to the cache. This is only relevant for the uses case around playlist and NowPlaying images.
The problem is different, and I still assume this is related to in-memory cache. Especially, as you wrote the re-loading is done very quickly.
@kambala, if NSCache anyway handles its size on its own, taking into account device's low memory situations, do we then really should to set a max cost limit and clean NSCache on applicationDidReceiveMemoryWarning?
Edit: needed to change my statement on NSCache cost. The API is used correctly.
RE: Testflight access to beta version - amasephy - 2024-01-18
I rolled back to previous test flight.
For me the problem does not manifest simply from cold app boot. More than likely I will have to wait until tomorrow to see if it’s an issue still on this old release.
I will say doing a cold boot there is a very slight hesitation when opening the libraries even when artwork is not an issue. This is probably expected behavior.
Of note though is I’ve started noticing flakey connections when starting the app. Before I rolled back and doing a cold boot, the first time the app attempted to connect to the server it failed. Tapping on the server to try again it immediately connected. This isn’t the first time I’ve seen this issue recently.
RE: Testflight access to beta version - Buschel - 2024-01-18
Thanks for evaluating an older version.
Few more informations:
- Since migrating to the new version of SDWebImage the storage cache images are removed after 1 week, before it was 1 month. I should roll back to 1 month to avoid ineffective cache for weekend-only users.
- In-memory cache is emptied on app restart, when moving app to background (e.g. when bringing another app on screen) or if iOS signals device memory warning
- In-memory cache is filled when accessing or saving a storage cache file. So it needs to rebuild on each new app restart or after moving the app to background.
- Only with images in in-memory cache you will get the fully responsive scrolling experience
- In consequence each first-time scrolling of a certain list after restart/sleep might show quick loading until all images are loaded to RAM. But this is expected and did not change.
- I also checked global search: if you already have entered the movie list (list view) before, the images are already loaded to RAM and not reloaded for global search. Also as expected.
@amasephy, what exactly you mean by "cold boot" or "app cold boot"?
RE: Testflight access to beta version - amasephy - 2024-01-18
I thought I was using UlfSchmidts term with cold boot but what I mean is force closing the app and relaunching it. As in not just simply suspending and resuming the app.
RE: Testflight access to beta version - Buschel - 2024-01-18
Ok, got it.
RE: Testflight access to beta version - kambala - 2024-01-20
(2024-01-17, 22:45)Buschel Wrote: @kambala, if NSCache anyway handles its size on its own, taking into account device's low memory situations, do we then really should to set a max cost limit and clean NSCache on applicationDidReceiveMemoryWarning?
cost limit never hurts IMO
explicit cache cleaning on memory warning sounds superfluous though, as NSCache does something similar on its own already (but I think it discards objects only partially)