2023-03-20, 07:48
Could it be that the loading simply takes longer from NAS via Kodi API? You could test this via moving one of the long-loading TV shows to the Kodi server and scan it to database from there.
2023-03-20, 20:23
I could try but wouldn’t explain why certain shows don’t exhibit the problem.
Fwiw, everything is hardwired gigabit connection.
Here’s a video showcasing how slow it is. 20 seconds to load the artwork.
Fwiw, everything is hardwired gigabit connection.
Here’s a video showcasing how slow it is. 20 seconds to load the artwork.
2023-03-20, 20:55
Really takes some time to load the images ... Does this change when disabling "rounded corners" in the App settings?
2023-03-20, 21:22
Funny you mention that, when I wiped the app from the phone for testing I forgot I had to reset all of my preferences. I could have sworn I turned off rounded corners.
I’ll check later. Testing this is a pain because I don’t want to reload all preferences constantly but need the cache cleared in order to actually compare loading times.
Edit: this is using square corners.
Sounds like it’s a difference in the way Kodi scrapers manage art vs Ember. Still, the internal scraper uses local art and scans it into the database so it shouldn’t matter.
One more thing - is your artwork directly in the Kodi database? When using Ember Media it drops the artwork into easily viewable files and folders for each show. For example, the actors are in a .actors folder. I don’t normally get actor images in a folder if I use the built in Kodi server art scrappers. I feel like this problem started when I started using Ember Media manager.
I’ll check later. Testing this is a pain because I don’t want to reload all preferences constantly but need the cache cleared in order to actually compare loading times.
Edit: this is using square corners.
Sounds like it’s a difference in the way Kodi scrapers manage art vs Ember. Still, the internal scraper uses local art and scans it into the database so it shouldn’t matter.
One more thing - is your artwork directly in the Kodi database? When using Ember Media it drops the artwork into easily viewable files and folders for each show. For example, the actors are in a .actors folder. I don’t normally get actor images in a folder if I use the built in Kodi server art scrappers. I feel like this problem started when I started using Ember Media manager.
2023-03-20, 22:04
Yes, I only use the Kodi internal scraper.
2023-03-21, 03:59
Plot thickens…
Movies loads in the actors slowly too. But, no spinner ever shows up. The poster art does immediately load though. The last thing to load is the fanart used for ken burns which does take probably the 20 seconds.
Maybe for movies the spinner is not enabled? Strange that movies wouldn’t have the same issue. There’s way more actors in movies, same Ember Media manager, and same high resolution content. There’s gotta be some difference in the app if it works fine on movies but not Tv shows.
Edit: Accessing movie details from the “Added Movies” view (the one I said I liked the unique layout on a few weeks back) results in a split second spinner in the view before loading the movie details. This results in the ken burns fanart being available immediately vs accessing it from the plain movie view. There’s definitely a difference in how the app is pulling in the data.
Maybe you can change artwork priority. Really the poster and fanart for ken burns should be given priority for loading. Actor art can “lazy load”.
Movies loads in the actors slowly too. But, no spinner ever shows up. The poster art does immediately load though. The last thing to load is the fanart used for ken burns which does take probably the 20 seconds.
Maybe for movies the spinner is not enabled? Strange that movies wouldn’t have the same issue. There’s way more actors in movies, same Ember Media manager, and same high resolution content. There’s gotta be some difference in the app if it works fine on movies but not Tv shows.
Edit: Accessing movie details from the “Added Movies” view (the one I said I liked the unique layout on a few weeks back) results in a split second spinner in the view before loading the movie details. This results in the ken burns fanart being available immediately vs accessing it from the plain movie view. There’s definitely a difference in how the app is pulling in the data.
Maybe you can change artwork priority. Really the poster and fanart for ken burns should be given priority for loading. Actor art can “lazy load”.
2023-03-21, 08:08
There is no different handling for any of this. It always does:
1. load thumb (uses cache)
2. load fanart (uses cache)
3. load clearlogo (not cached)
4. load actors (not cached)
I can sometimes see all actors finishing before thumb and fanart are loaded, especially when there is no cache hit for thumb and fanart. But still the actors shall load in no-time.
1. load thumb (uses cache)
2. load fanart (uses cache)
3. load clearlogo (not cached)
4. load actors (not cached)
I can sometimes see all actors finishing before thumb and fanart are loaded, especially when there is no cache hit for thumb and fanart. But still the actors shall load in no-time.
2023-03-21, 12:38
Guess that exhausts every possibility. I’m not terribly bothered by what I’m experiencing. It’s not that big of a deal.
Thanks for taking it as far as you could, creating special test builds for it and such. Much appreciated!
Thanks for taking it as far as you could, creating special test builds for it and such. Much appreciated!
2023-03-24, 00:32
(2021-04-19, 22:41)kambala Wrote:(2021-04-19, 20:17)Buschel Wrote: In the queue for next test builds are further fixes, some app-internal cleanups and support for Apple Watch.
I also plan to add https://github.com/xbmc/Official-Kodi-Re...issues/191 and https://github.com/xbmc/Official-Kodi-Re.../issues/75
next build is going to include watch app I think.
Since one month I have an Apple Watch and I am happy to see there are some plans about to implement a Kodi remote Watch app (https://github.com/xbmc/Official-Kodi-Re...OS/pull/91).
Unfortunately the person who provided this pull request is already quiet since 2022. Are there any possibilities this project could be continued somehow? I am not a programmer, but off course I can test the results. Thanks
2023-03-24, 22:17
The Apple Watch support needs someone to pick up the changes from where they are. In its current state there are merge conflicts which make it impossible to even provide test builds.
2023-03-25, 15:36
13.0 build 3819
Release Notes
This build fixes a regression which came with the first 13.0 build, improves the fullscreen fanart experience on iPhones, adds two features (selectable dark/light theme, support RunScript favorites) and does quite some refactoring for better future maintainability of source code. The latter was thoroughly reviewed but it will be good to just check your use cases and report if anything behaves different as expected or as before.
What's next? The AppStore soon requires XCode 14.1 when uploading Apps. This will update the SDK and typically introduces undesired behavioral changes. The migration is already prepared and you will see another TF version coming up soon, which will really need some deep testing.
Release Notes
This build fixes a regression which came with the first 13.0 build, improves the fullscreen fanart experience on iPhones, adds two features (selectable dark/light theme, support RunScript favorites) and does quite some refactoring for better future maintainability of source code. The latter was thoroughly reviewed but it will be good to just check your use cases and report if anything behaves different as expected or as before.
What's next? The AppStore soon requires XCode 14.1 when uploading Apps. This will update the SDK and typically introduces undesired behavioral changes. The migration is already prepared and you will see another TF version coming up soon, which will really need some deep testing.
2023-03-27, 18:04
2023-03-27, 18:42
Nice, thanks guys. Then we can begin with the next step, the SDK update.
2023-03-28, 03:04
I did just notice a very small visual quirk. Nothing new in test flight, likely always been this way. Almost imperceptible but I noticed a slight extra unexpected flicker when flipping between the Now Playing views. I recorded a video of it to analyze. Maybe it was designed this way, if so disregard!
Basically when the current view of now playing is triggered to dismiss and flip to the other view the animation does a 180 flip of the view before totally fading away. On entry, the view does not do a 180, just the expected 90 rotation into view. I believe the point of this style animation is to give the illusion that each view is “back to back”. However, doing a full 180 flip then fading betrays this illusion. I would think it would rotate 90, thus becoming invisible, then rotate the other view into view.
Again, very minor. Here’s a video demonstration.
Basically when the current view of now playing is triggered to dismiss and flip to the other view the animation does a 180 flip of the view before totally fading away. On entry, the view does not do a 180, just the expected 90 rotation into view. I believe the point of this style animation is to give the illusion that each view is “back to back”. However, doing a full 180 flip then fading betrays this illusion. I would think it would rotate 90, thus becoming invisible, then rotate the other view into view.
Again, very minor. Here’s a video demonstration.
